[FFmpeg-devel] [VOTE] Equality and leader team
Sat Feb 5 17:26:06 CET 2011
On Sat, Feb 5, 2011 at 6:11 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Feb 05, 2011 at 06:02:35PM +0200, Felipe Contreras wrote:
>> How about this, you setup a system with patchwork, to keep track of
>> the patches, and the ack's. Then the system would commit the patch
>> with clearly defined rules, such as, it has been ack'ed by a
>> maintainer, _and_ one day has passed without nak's.
> There is the problem that huge parts do not have any maintainer (except
> Michael as a fallback, but that was removed together with the "leader"
> title), or the maintainers do not respond for months (!).
> Otherwise that would be a fine idea (ok, silly to say "a fine idea except
> that it doesn't work", but maybe you still get what I want to say).
That is a problem regardless. BTW, I didn't mean the bot would check
the the maintainer ack was for the part they maintain. Any maintainer
can ack anything, just like before maintainer could commit anything;
of course, 'can' != 'should'.
And of course Michael could remain as a fallback maintainer, I don't
think anybody would be opposed to that, except Michael of course.
>> You would need a
>> maintainers list, like in linux, which would be useful regardless.
> Uh, are you seriously not aware we have one? Or do you mean to say there's
> something wrong with the one we have? Or what??
Oh, I didn't know, but I meant a machine readable one, so you can do
>> I find this fight over committership ridiculous, the committers don't
>> matter, the maintainers do.
> My conclusion based on the discussion is that it is the other way around.
> Though the precise meaning of maintainer was never defined.
How so? If you have this patchworks setup where only the bot has
commit access, who has commit access is irrelevant, and there's no
difference with the current situation, because the committers are
acting like bots.
More information about the ffmpeg-devel