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. -Thilo _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
