[FFmpeg-devel] [VOTE] FFmpeg leader

[Luca Barbato]

On 10/02/2010 08:23 AM, Jason Garrett-Glaser wrote:
> 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.
>
> 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".

Looks like we might like a code review service like gerrit or since we 
could have a tool doing what you describe.

lu

[1] No, not gerrit.

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero