[FFmpeg-devel] Voting committee

Thilo Borgmann thilo.borgmann at mail.de
Wed Sep 16 10:11:34 CEST 2015

Am 16.09.15 um 09:04 schrieb anshul:
> On Monday 14 September 2015 10:50 PM, Nicolas George wrote:
>> L'octidi 28 fructidor, an CCXXIII, Ganesh Ajjanagadde a écrit :
>>> Looks mostly good to me. One thing I think that should be clarified is
>>> the meaning of "linear combination" - I assume you meant a non-trivial
>>> (exclude all zeros) linear combination over the nonnegative integers?
>> Thanks. You are right, this was imprecise. I meant linear combination with
>> total coefficients one; barycenter in other words. For example: 10 commits
>> are ok, 20 devel mails are ok, then 5 commits and 10 devel mails are ok too.
>> Of course, the value I have put are rather arbitrary. Please people feel
>> free to propose other values.
>> Regards,
> Some thoughts on voting commitee:
> It looks like maintainer list is ignored. Like if there is maintainer of XYZ
> feature. and decision of XYZ features are taken by committee then ignoring him
> just because he don't have lots of commit would be bad idea. Maintainer has
> taken responsibility so until he is not removed from maintainer list from that
> part and his place is not filled by someone else.
> There could be conflicts like if XYZ part is not developed well or used by many
> people take snow or ffserver for example people want to remove it completely.
> Since majority of comitee don't like that feature then that does not mean that
> they are authorized to remove that part. If there is no maintainer for some part
> they can remove it to decrease work load but if there is maintainer they must
> not over rule him.

Removing a maintained part of FFmpeg might be the extreme example - I think the
listed maintainer always deserves to be part of the voting committee whenever
the decision in question directly affects the maintainer's part of FFmpeg.

> There should be restriction on voting committee to remove some part of FFMpeg,
> or I fear that bad voting committee can tear this project apart.
> There may be one more scenario like there is committee of  20 people where 11
> voted on X way and 9 voted on Y way. and at end of day 9 voter forked ffmpeg and
> made there own project.
> So I would put one more restriction here that its not about what majority wants 
> X way or Y way there should be what reasons are given to follow X way or Y way.
> and confirmation that everyone understand pros and cons of particular way. No
> valid reason given against anyones wills other then majority voter should be
> avoided at any cost or we may loose developer.

I think that having a list of decisions deserving more than simple majority
might be overkill. At the end there will always be developers leaving for not
being happy about democratic decisions.


More information about the ffmpeg-devel mailing list