[FFmpeg-devel] Development polices of the FFmpeg

Roman V. Shaposhnik rvs
Thu Sep 11 04:21:35 CEST 2008

Hi Diego!

On Wed, 2008-09-10 at 18:57 +0200, Diego Biurrun wrote:
> Sorry for butting in late, this has been lying in my drafts folder for
> far too long.  Nonetheless I felt I should write something even though
> not every one of my opinions is thought out until the end...

I'm glad you decided to answer.

> > For example, when Michael throws a moody about something as trivial
> > as: ((s->buf[1]>>2)&0x3) == 0 vs. (s->buf[1]&0xC) == 0. Is it something
> > that would be of a concern to anybody but him? And if not, should
> > he be payed attention to *IN THIS PARTICULAR CASE* (to be extra
> > clear this is the case of a code NOT officially maintained by him).
> I do not think anybody should "throw a moody" about this, but I do
> wonder why you do not incorporate this neat simplification...

I will. Absolutely. That was something I clearly overlooked and I'm
happy that it got caught. Really, it is all about how one says things.
"Hey, you've just committed this bit of code that could be simplified"
vs. "Get your stupid code out of here. All of it." are two different
ways of pointing out the same thing. They all achieve the same result,
but the first one makes you feel like a likable goof, who is, even while
goofing up among friends. The other one... well, more on that later.

Oh, and by the way, except for the 2 outstanding issues that I still
haven't seen Michael's response on and the tables all his other 
suggestions were spot on. And had he commented the same way he
eventually did on cvs-log, two weeks ago -- this thread would not
have existed.

> I do not think such things should be reverted, but I do not see reasons
> not to attempt further cleanups.

Absolutely agreed! And that's exactly what I'm doing right now. Once
again, I don't deny that there has to be a line drawn for accepting
code into SVN. And there has to be a policy in place that if Michael
(or anybody else for that matter) have any kind of suggestions they
have to be dealt with in a reasonably fast manner. Clearly if somebody
dumps gobs of OKish code into SVN and then disappears -- it might be
best for everybody if that code goes too. I believe we all are in
agreement on these things.

What got me really pissed off, though, was the initial attitude and
especially the way it was communicated. It clearly made me feel
very unwelcome and worse yet as somebody who simply wastes Michael's
time without giving anything back. 

Now, I could very well imagine that every time Michael sees a patch
submitted for review, he does indeed throw his hand in the air and say
"Oh my! How could anybody who writes such a code could still do
software!". Being in a position to review code from contractors and
vendors I could actually appreciate how painful that could be. 
So the question then, becomes, if reviewing my code is really that
much a of detraction and pain for him may be his message really was
designed to make me feel "unwelcome". And if it is, indeed the case,
then I would be the first one to acknowledge that the best thing
I could do is to stop bugging Michael, get the code out of SVN 
and start doing knitting as a hobby.

But the bigger question I had was: will me picking up needles be a net
win for the project or a net loss? And that's why I created this

> If you have a look at
> http://wiki.multimedia.cx/index.php?title=Interesting_Patches
> you will find more stuff including things like WMV3, H.264, AMV, Chinese
> AVS encoders, zlib, Bink, G722, SIPR decoders and many other things.
> Some of these things have reached FFmpeg in the meantime, others still
> have not.  I'm sure many of them would have been incorporated already
> into projects with less strict requirements.

Indeed. That is a very good observation. Worse yet, many engineers
would have participated had it not been about constant abuse of
"If you can't stand the heat -- get out of the kitchen" principle.
I have private communications from member of other multimedia related
projects telling me exactly that. To some extent -- they threw in the
towel. Was that a net gain for the FFmpeg? I'm pretty sure it is
a net gain for Michael as a person who is supposed to have some private
life. But isn't the project lead supposed to not only foster technology,
but also a development community around it? Personally, I used to
do it all the time. Different folks would send me their code and 
ask whether it could be included into FFmpeg. I got my share of
bad code, but on NO occasion did I make the submitters feel unwelcome.
In fact, sometimes, when I saw the they were simply not interested
in cleaning it up -- I would take their code, say "thank you so much"
and proceed with cleaning it up myself. DVCPRO HD is sort of like
that (although Dan's code is usually pretty good) where the
final commit doesn't look very much like the original patch.

Can something like that be the norm around here, instead of an
exception? Can we err on the side of making submissions and
submitters feel welcome here, rather than constantly demanding
that they prove their worth to us first and only the accepted
to the club? Is this too much to ask?

> Whatever gripes people have with FFmpeg or its leadership, there is no
> alternative to it and many people accept the way things are handled even
> if they may not agree.

Agreed. Nobody but Michael passes the "fork test" (well, I do not
pass it for sure, may be I just don't know some of you guys all
that well). So, the bottom line is: "if you can't stand the
head -- get out of the kitchen" :-( 

> Roman, sometimes you cannot change things, but you can always change
> your attitude towards them.  Don't take any of Michael's comments or
> flames too seriously or personally.  Just swear or leave the computer
> for a while and then get it done.  You can think of sharing a few beers
> with your buddies at the next LinuxTag if that cheers you up.
> I know it works for me, you might give it a go as well...

That sounds like a very good advice, indeed. And I would love to follow
it. Michael, you are invited too ;-) (hey, I can buy you some beer
to remedy the pain of looking through my changes).

> Your contributions are welcome now and will still be welcome in the
> future.  It would be a shame to see you go...

Thank you. It really is nice to know that you DO have an answer to
my question. Thanks for stating it explicitly.


P.S. Michael, if you've read this far -- you are one fair dude ;-)

More information about the ffmpeg-devel mailing list