[FFmpeg-devel] [VOTE] FFmpeg leader

[Jason Garrett-Glaser]

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

Dark Shikari