[Ffmpeg-devel] I'm giving up

[Michael Niedermayer]

Hi

On Tue, Dec 05, 2006 at 10:51:51PM +0100, Eduardo Morras wrote:
> At 22:03 04/12/2006, you wrote:
> >Takis, Michael offered  you to create a branch on ffmeg svn
> >repository. If you do that, your incremental changes will be public
> >(and hopefully much easier to review), and everyone with svn write
> >privileges may help you.
> >
> >I do understand that you would rather have your changes merged right
> >away, but well... better have thing get forward than blocked.
> 
> In other projects, f.e. freebsd, there is a stable branch and a 
> develop branch, things go from develop to stable when they work and 
> are well tested. Perhaps ffmpeg comitter staff can do something like this.

no, there is no need for this, we can create branches if they are needed
for specific things but general development is done in the main branch
you are free to fork if you disagree ... its clear you are trying to solve
some problem which doesnt exist and by doing so would introduce a much
bigger one (= more work maintaining 2 branches)


> 
> Also, i think a working codec doesn't need to be perfect and 
> optimized for commit, it needs to work without errors and follow the 
> coding rules. 

did you read my review of the code? did you read the svn policy and
coding rules
if not please do that before complaining


> If not, almost all current code must be drop off from 
> svn because they arent optimized or implements partially a codec. 
> Think about snow, is it finished? and fully optimized?, no, then 
> decomit it from svn; which other codecs have now open bugs? decomitt 
> them too. You must note that you are demanding from casual helpers a 
> level of perfection which your own code don't reach. Don't accept a 

if you know of specific issues in specific code in svn report them, ideally
with patches or suggestions of how to improve the situation
you are free to review my code and complain about things if you dont then
stop complaining

and anyway the goal is clean, simple, optimal, fast, bugfree... code in svn, 
i think the rules are fair, if not thats a pitty, but the first goal i have
is optimal, ... code in svn, fairness is just on the second place but i see
little unfair about the rules ...

also everyone can fork ffmpeg and create their "apply everything world" but
noone will clean up code or fix non critical things there because if people
would be wiling to fix issues they would have done it already when someone
pointed at them in a review ...

take the h264 encoder example, IIRC takis said his boss doesnt like all
the work and delay to get it applied and if the rejections continue will
likely just keep the h264 encoder in their own "fork" so what are the
options? apply it? if we do, do you think takis boss will say great lets
now clean up the code? or will he say great its in lets work on something
else for which we get some money? of course i dont know what would happen
and also i know no details at all so maybe my reasoning is fundamentally
flawed but in general its true IMO that requireing code to be cleaned up
before commit is a much quicker and effective thing then just hoping
someone will do it after commit ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali