[FFmpeg-devel] [VOTE] FFmpeg leader

[Stefano Sabatini]

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

Discretion is left to the maintainer into ponderating what is to be
considered "trivial".

I don't think such exceptions are too much restrictive, neither are
too difficult to follow.

Note that even with these restrictions the maintainer of the
respective file/code has the last design choice (but the project
leader can object on that), but following strictly such rules may
prevent most post-commit flames.

I don't think we want to assume this rule: 

* the project leader is no special in regards to the committing
policy, so he has to post all his non-trivial patches and he has to
address all the issues raised before the commit

which would sound too restrictive and would possibly slow-down the
development.

What we should try to achieve is some tradeoff between the need of the
leader to have control on the project and the need of the other
developers to have voice into the development and design of the
project. This is far more important than resolving the bikeshed of the
day, and such achievement would benefit the whole project (including
the maintainer himself), and would possibly make FFmpeg a better
"environment" where to stay and contribute.

Regards.
-- 
FFmpeg = Freak Fiendish Martial Puristic Elected Gorilla