[FFmpeg-devel] [VOTE] Equality and leader team

Nicolas George nicolas.george
Sat Feb 5 18:54:56 CET 2011

Le septidi 17 pluvi?se, an CCXIX, Felipe Contreras a ?crit?:
> How about this, you setup a system with patchwork[1], 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. You would need a
> maintainers list, like in linux[2], which would be useful regardless.
> Then _nobody_ would have commit access, only the patchwork bot, and
> according to your definition of "power", nobody would have it. But if
> you think about it, how is that any different from the current
> situation? Who has commit access is irrelevant, because they are
> abiding by the same rules of the bot. The committers are doing some
> legwork, that's all.

I like that idea.

> I find this fight over committership ridiculous, the committers don't
> matter, the maintainers do.

I think you are right, and your message has made me understand one of the
things that are wrong with the coup: it tries to solve a human problem with
a technical solution. As we saw (with the misapplied patches) but as
everyone already knew, this does not work. A human problem needs a human
answer; a technical solution can be part of the answer, but it can never be
the sole solution.

The same goes for the tool you suggest: people are talking about
machine-readable maintainer database, but we do not need that. People who
are allowed to approve patches are supposed to be trustworthy, they can be
trusted to obey the policy, if the policy is clear enough. If they don't,
they get flamed. If they don't repeatedly, they get an ultimatum and lose
their right to approve.

Now, the patchwork-approve-apply system comes into that because it makes it
easier to check that the policy has indeed been applied. Just that. It is
not the solution, it is just a tool to help the solution.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110205/7a1d3b09/attachment.pgp>

More information about the ffmpeg-devel mailing list