[Ffmpeg-devel] I'm giving up

Eduardo Morras nec556
Wed Dec 6 04:39:09 CET 2006

At 23:45 05/12/2006, you wrote:
> > 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)

That's true, 2 branches, double work

> > 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

Yes, i have read svn policy and coding rules but, you are taking my 
words on the "bad side". I was saying that if all the svn policy is 
applied equally to everyone that wants to commit changes to svn code, 
there are a lot of actual code that can't be there because has bugs. 
Check everyday mail on the list, there are patches for bugs for code 
that should work. Why accepted before that buggy code and reject other now?

> > 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

Then i'll stop

>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 ...

I agree with the svn policy, if there's noone, it'll be a chaos. 
Again, i was saying that for some people there a some rules, for 
other are a bit more relaxed.

>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 ...

That's what i do, i forked ffmpeg on my computer and i'm implementing 
GOG video codec. But want to share the code also and follow the 
coding styles. But if it isn't optimal or i use valid c constructs 
(for ffmpeg coding policy) in ways the comitter dislikes, must not be 
a reason for reject it. Optimizations, faster/smaller code and other 
more complex algorithms should be coded after commit, this way more 
people can read the clear code. It's not the same read 5 lines of 
simple than 20 of optimiced. First make it run, then make it run fast.

>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 ...

No, don't apply it to make his/her boss smile. Apply if it follows the rules.

>Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Now, i'll stop.


More information about the ffmpeg-devel mailing list