[FFmpeg-devel] [RFC] About committership

Tomas Härdin tomas.hardin
Wed Feb 2 21:11:17 CET 2011


Stefano Sabatini skrev 2011-02-02 16:17:
> On date Wednesday 2011-02-02 09:09:06 -0500, Ronald S. Bultje encoded:
>> Hi,
>>
>> let's not make this a terribly long thread, and therefore focus on
>> your core point only:
>>
>> On Wed, Feb 2, 2011 at 6:10 AM, Stefano Sabatini
>> <stefano.sabatini-lala at poste.it>  wrote:
>>> And finally my proposal: to review the committership mechanism, I
>>> propose to restore the previous model, to give back commit rights to
>>> all the developers and enforce *via policy* some of the new rules, for
>>> example to require the approvation of non-controversial patches from
>>> at least another developer with expertise in the area. The queueing
>>> mechanism looks *good* and may be extended to all the developers.
>>
>> What do you want to achieve by doing this?
>> - are we not committing your patches fast enough?
>> - do you feel like you lost control over your subsystem?
>> - do you feel like we bully you or veto your patches?
>> - something else?
>
> I don't want to beg for getting my patches applied, I want to be able
> to commit them myself, provided that the patches have been reviewed
> and approved by the maintainers of the affected areas, and do the
> commit work myself, without requiring the intervention of others.
>
> If this can't be achieved for some reason, that's fine, provided that
> there is a discussion about it and is clear which are the rules
> which govern the project to which I'm devolving my time and my work.

What about a hybrid system? Something that allows eager developers to 
push, but still somehow makes sure untested commits never reach the 
public repo.

Here's a modest proposal:

Have a "quarantine" repository to which every 
maintainer/developer/committer/whatever has push access. Have the 
queueing and testing system work the quarantine repo. Finally, have the 
system push the new patches to the official repo as soon as they pass FATE.

This way patches can be pushed for queueing and testing by everyone, but 
obvious mistakes won't make it through the tests.

/Tomas



More information about the ffmpeg-devel mailing list