[FFmpeg-devel] [VOTE] FFmpeg leader

[Felipe Contreras]

Hi,

On Sat, Oct 2, 2010 at 11:25 PM, Baptiste Coudurier
<baptiste.coudurier at gmail.com> wrote:
> On 10/2/10 5:29 AM, Felipe Contreras wrote:
>> On Sat, Oct 2, 2010 at 12:49 PM, Baptiste Coudurier
>> <baptiste.coudurier at gmail.com> wrote:
>>> Please let's be reasonable. We are all here for fun (for now at least).
>>> Given the man power available, given the work, we cannot reasonably
>>> enforce strict rules like you would do in projects like the kernel,
>>> where day jobs and money are involved, let's face it.
>>
>> This rule, or guideline rather, ensures code quality, and fairness. I
>> don't see how sending patches to the mailing list first would be any
>> less fun... it tells the community "I care what you think, and I care
>> about the quality of this code'.
>
> Well, it seems you are part of this "community", did you ever review a
> patch on ffmpeg-devel that you didn't send ?

I don't consider myself part of this community (yet), I just wanted to
provide feedback as to what other projects do. I do read patches, and
perhaps I've made a comment or two, but I don't think I know enough of
the culture here.

>> Also, you are assuming (for some strange reason) that everybody that
>> works in the kernel is doing so because they are getting paid; I think
>> you are completely wrong. People contribute to linux mainly because
>> it's fun, and challenging, and it matters. Some people coincidentally
>> do get paid, but they anyway keep contributing on their own free time,
>> abiding by the same rules. And the majority of people are not paid in
>> any way:
>>
>> http://lwn.net/Articles/222773/
>
> I believe you are confusing "maintainers" and "contributors" here.

How exactly? Should maintainers be allowed to "have fun" and
contributors not? I think the definition of maintainer is different
here than in the kernel; there a maintainer can decide not to be a
developer (only review and merge patches); the two roles are
separated, when a maintainer decides to develop, he does so as any
other developer and submits patches for review.

IMO contributing patches should be fun for everyone, regardless of their rank.

>> And what about projects like git? Or vlc? The developers surely don't
>> get paid for contributing, and still send each and every patch (or
>> mostly).
>
> I didn't say developers on git were paid, I don't know about that.
> Like I already said git is a major project, and cannot be compared to
> FFmpeg in man power, number of active contributors, nor maintainers.

But how do you think they managed to gather so many contributors? Take
a look at these numbers:
http://article.gmane.org/gmane.comp.version-control.git/135659

In git everybody is equal, that's why it's so easy for new people to
get involved, do a bunch of changes for one release, and then
disappear, and in every release a big amount of changes is contributed
this way.

I think the problem with the maintainer vs contributor mentality is
that once you become a maintainer, you have trouble making sure that
things are smooth for the rest. If everybody is bound by the same
rules, then everybody is vested in the same development process.

If you are saying that the development process for non-maintainers is
too burdensome for you, then perhaps it should improve. It's not fair
that the rest of us has to go through all the plain to become
maintainers before actually start having fun.

>> By the time it hits the SCM it's too late, it has tainted the
>> history... forever. Why would you want to do that if you already have
>> an alternative that works in so many other projects?
>
> May I ask you why you think it "taints" the history ?
> I don't mind having mistakes in the commit logs, because it shows
> honesty, nobody is perfect.

Why do you want to see mistakes in 'git log'? We all undo, rebase
commits, amend, squash, etc. Nobody cares about being honest and push
all those mistakes. Sure, nobody is perfect, but if you have a process
that gives better quality, why go for the less than ideal one?

If you go hunting a bug one year back you most certainly would not
like to see a commit split in two or three: a buggy one, a fix by
developer B, and then another one by developer C all on the same code.
Sure, that's "honest" but it's wasteful.

Cheers.

-- 
Felipe Contreras