[FFmpeg-devel] Development polices of the FFmpeg

Roman V. Shaposhnik rvs
Fri Aug 29 23:21:28 CEST 2008


On Fri, 2008-08-29 at 11:42 -0700, Baptiste Coudurier wrote:
> We all work for the sake of bringing FFmpeg up here, and we all have the
> same goal, we also have differents commitments and interests, discussing
> as a "team" is needed, not necessarly in a "pyramid" way (Michael /
> single dev people), however Michael tends to do everything around here,
> so this is less obvious IMHO.

That is really the crux of the problem. I don't think I can be part
of the Michael's FFmpeg. He obviously doesn't seem very highly of
me (not without a merit, though: compared to me he IS smarter and he IS
a better coder -- I'll be the first one to admit that) and we both
don't need the kind of aggravation we seem cause to each other. On
the other hand, I would LOVE to be part of the FFmpeg of you, M?ns,
Mike, Kostya, Diego and a dozen of other developers who I greatly
respect. I just need to figure out what kind of project it is nowadays.

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

Another example -- should threatening to revert the changes in the
pieces of code that he doesn't maintain over trivial issues be his
usual modus operandi, or should there be SOME level of involvement
of other developers to decide whether such drastic measures are
really called for, or whether it is better for the project
to try and resolve issues first (with the code in question being
in SVN) and only if it fails remove the offending parts.

Here's the deal: I used to contribute to FFmpeg much more
actively a three years ago or so, but then I went through
a period in my life where any major coding outside of my
immediate employment was more of a luxury. I'm now back
on track. I still have lots of interest in doing multimedia
as my hobby. I also believe that I am capable of being mildly
helpful to the overall success of the project, even though
the nature didn't bless me with the kind of gift that 
somebody like Michael is blessed with. Precisely because
of that I'm also prepared to happily receive the kind
of technical guidance that was exemplified by 
dv100_dct_mode vs. mb->dct_mode change. The only thing that
I ask for is that I work with a team instead of a single
individual with his likes and dislikes and the team
decides over the matters, instead of the individual
lashing out at you over trivialities. Is it too much
to ask for in return to the kind of work I am capable
of? I honestly don't know. But please DO tell me.

Again, sorry for the digression, I just didn't want
it to look like it is simply about me ramming DVCPRO HD
code through. There's actually much bigger question
for me at stake here.

> Working around here is _not_ easy and we need to encourage ourselves.

Once again, the only thing I'm asking for that it is a TEAMwork
instead of a dictatorship.

> > I have 0 contract money at stake here. And trying to imply that I do
> > is just pathetic. I knew you were a pompous jerk, but I would never
> > imagined that you would go as low.
> 
> Well, Dans had, and some people already offered bounty for this work, so
> while the commitment and the cleanup of Dans is clearly _obvious_, and I
> think Michael should have realized it, this is not 100% true that there
> is no contract / money behind DVCPROHD as a whole.

I guess the above is the kind of truism that is always there. Of course
I will gladly accept any kind of financial (or hardware) donation
for my past work.  But it is quite different from working under 
contractual obligations that regulate what you're supposed to
do in the future. I have never done that around FFmpeg and I don't
intend to do it any time soon.

Thanks,
Roman.

P.S. Thanks for acknowledging my contributions to FFmpeg. Even though
honestly most of them are trivial compared to what Michael does.





More information about the ffmpeg-devel mailing list