[FFmpeg-devel] [VOTE] FFmpeg leader

[Baptiste Coudurier]

On 10/2/10 2:00 AM, Stefano Sabatini wrote:
> On date Friday 2010-10-01 23:23:48 -0700, Jason Garrett-Glaser encoded:
>> On Fri, Oct 1, 2010 at 11:12 PM, Baptiste Coudurier
>> <baptiste.coudurier at gmail.com> wrote:
>>> On 10/1/10 11:09 PM, Jason Garrett-Glaser wrote:
>>>> On Fri, Oct 1, 2010 at 10:57 PM, Felipe Contreras
>>>> <felipe.contreras at gmail.com> wrote:
>>>>> On Sat, Oct 2, 2010 at 8:47 AM, Jason Garrett-Glaser
>>>>> <darkshikari at gmail.com> wrote:
>>>>>> And since your maintainership covers all of ffmpeg, that gives you the
>>>>>> right to change whatever you want without asking anyone.
>>>>>>
>>>>>> How about no.
>>>>>
>>>>> In some projects, like git.git, the maintainer sends his patches to
>>>>> the mailing list like everybody else. If nobody shouts, he pushes. I
>>>>> believe this is the most sensible approach; the maintainer should not
>>>>> be considered a flawless god whose opinion is above everybody else,
>>>>> and thus his patches should not be considered error free, nor
>>>>> unquestionable.
>>>>
>>>> I agree.  Not even Linus commits his patches unquestionably; Michael
>>>> should be the same.
>>>
>>> Well FFmpeg is not like the kernel (where everybody is paid to do the
>>> job) nor a major project like git which has many contributors.
>>>
>>> I would personnally be really annoyed to send patches to files I
>>> maintain. I do however pay really attention to comments made on -cvslog,
>>> and I address them. Many people review on -cvslog as well.
>>>
>>> Given the coverage FFmpeg svn has now thanks to FATE, this is reasonable
>>> IMHO, and avoids the burden.
>>
>> I think we need something in between x264's and ffmpeg's style for
>> dealing with files we maintain.
>>
>> 1.  We want people to be able to review each others' patches,
>> preferably before they're committed.
>> 2.  I *WANT* other people to review my patches, preferably before
>> they're committed, even on files I maintain!  I don't feel comfortable
>> "just committing and seeing how FATE goes".  I think code quality
>> suffers massively because of this; communication and collaboration can
>> result in all kinds of things you would have never thought of alone.
>> I've made tons of mistakes maintaining ffvp8 that someone else would
>> have caught if we had patch review.
>> 3.  But we also want there to be relatively low friction in committing changes.
> 
> I agree on this.
> 
>> x264's system is one where we push patches every week or so and have a
>> centralized repository (me) for handling patches.  The system is built
>> heavily around every patch getting reviewed by anyone who wants to,
>> possibly many times, before the final commit.  Obviously this is not
>> very suitable for something as large as ffmpeg, but I think we can get
>> some of its benefit.
>>
>> Here's my proposal:
>>
>> 1.  For any non-trivial patch to code you maintain, especially if it
>> isn't utterly urgent, when you think your patch is ready, you do a git
>> send-email to the list.  We might have some sort of extra tag in the
>> subject to tell readers that a patch falls into this category of
>> automated sending.  As a committer, of course, you just commit
>> locally, so to you, it is no different than if you pushed to trunk --
>> you can go on and develop other things.
>>
>> 2.  If nobody says anything in 3 days, you're free to push that
>> commit, no questions asked.
>>
>> 3.  The maintainer is *not* required to hold up his patch to deal with
>> every comment by non-maintainers.  However, he should read and take
>> into account each one.  Of course, a comment by another maintainer
>> could be a blocking matter.
>>
>> Maybe this is too much work.  Maybe it's a stupid idea.  But I don't
>> like the current system, which seems to encourage "committing without
>> having anyone else look at it".
> 
> Also I'd like to add that that style of committing hurts the
> community, and depreciate the other developers role in the project.
>
> Up to now the assumed policy has been:
> the project leader can commit anything related to the file/code he
> maintains, other developers have no right to discuss such changes
> before they are committed
> 
> Note that from my reading of the policy there is nothing which
> explicitely prevents such a rule from existing.
> 
> 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.

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.

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.

Now regarding the "principles",  I agree there should be one mentioning
that any public API/ABI change should be discussed on ffmpeg-devel first
and that a group of trusted people should validate it and agree with it
before it can be applied.

I think FFmpeg team is full of very talented devs, and I believe we
should maybe introduce a _group_ decision mechanism in the development
process.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org