[FFmpeg-devel] [VOTE] FFmpeg leader

[Felipe Contreras]

On Sat, Oct 2, 2010 at 12:49 PM, Baptiste Coudurier
<baptiste.coudurier at gmail.com> wrote:
>> I believe we agree that maintainers are free to apply patches on the
>> files they maintain, but in general there should be some exceptions to
>> this rule. Such exceptions may arise when:
>>
>> * the change affects the policy or the style of the project
>> * the change is no trivial, so it may benefit from peer-review
>> * the change affects other code not maintained by the committer *or*
>> ? the public interface
>
> 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'.

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/

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

It should be fun for you to receive constructive criticism from your
peers, which in the case of FFmpeg, constitutes very highly skilled
individuals, perhaps the best in the world in multimedia, I don't see
how you would find it more exciting to pass the opportunity of getting
such valuable feedback.

> Nobody "sneaks" in commits thinking nobody will have a look, and I don't
> think it hurts the community nor depreciate any other developer.
>
> About maintainership, I trust all of them are doing their best to ensure
> their parts are in good shape and review patches. Most people review in
> -cvslog like I said, and important issues are always quickly addressed.

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?

Besides it is fundamentally different:

1) code is developed *collaboratively*, sometimes the patch cannot be
considered to be written by one person, due to a big chunk of
comments. People don't feel left out of the process, many times they
are listed in the commit message. Also, since they feel comments are
welcome, they might even do some nitpicking.

2) code is developed individually; if somebody thinks the patch is not
right, tough, they would have to fix it... and of course their fix
would have to go through review because it's touching a holy patch
from a maintainer. People generally prefer to work collaboratively
rather than fix other people's mess, specially the ones from people
that are supposed to know better. And of course, if there's any
nitpicking involved you can pretty much forget about it because you
would have to write it yourself, rather than write one line right on
the text you are looking at.

> IMHO we should be able to follow general "principles" and act as a team,
> not being over-rigid about "policy" or "rules".
> We should base our teamwork on trust, and I believe we are still a small
> enough team to be allowed to do that.

Sure, I'm a maintainer in some projects, and I do commit some trivial
patches without any review, but when there's even a small risk of
getting it wrong, I send the patch first, because I do want it to get
it right, and for other contributors to don't feel like second-class
citizens, and it doesn't cost me anything (thanks to to git
send-email), just a little latency (in the case the code is right).

But trust has to be earned, and this whole thread seems to have
started precisely because somebody has abused that trust. I think it's
pretty clear that most contributors here agree that something needs to
change; whatever is being used by the maintainers the determine the
threshold of whether or not to send patches for review first, has to
be increased.

Cheers.

-- 
Felipe Contreras