Hi, I don't care much for MAINTAINERS, I certainly don't use it for anything, but ...
On Sat, Jun 11, 2016 at 12:31 PM, Michael Niedermayer < mich...@niedermayer.cc> wrote: > On Sat, Jun 11, 2016 at 01:55:01PM +0200, Clément Bœsch wrote: > > On Sat, Jun 11, 2016 at 12:57:13PM +0200, Michael Niedermayer wrote: > > > Hi > > > > > > the MAINTAINERs file contains a bunch of inaccurate and outdated > > > entries. > > > > > > What should be done about this ? > > > should we remove everyone who was inactive in FFmpeg > > > (aka no commit/author since 2 years) as in git log --first-parent ... ? > > > should we mark everyone above as inactive instead like "(inactive)" > > > > > > shuuld someone send mails to everyone and ask if they stil maintain > > > the code they are listed for ? > > > > > > > I'd say at most 30% of the file is still accurate, which means 70% of the > > file could be dropped. And then we'll see that it's so small the file is > > mostly irrelevant. > > > > Now I'd rather have the file used as a "community profile" to look for > > qualified people in the various area of the project; or said differently, > > keep only applications, misc areas, communication, generic parts entries. > > > > I feel like this file had for mission to be used as an argument to make > > sure people are indeed responsible for their code (as in "hey you're the > > maintainer of X, please review my patch"). Does it work? Did it in the > > past? > > The file serves as the foundation of "who has/should have/needs > git write access" and who has op on IRC > (this works and worked) > > It serves as a list of arbiters case of disagreement > (that wasnt used much at least not litterally) > > Without a MAINTAINERs file git write access and irc op could become > more disputable > > I do like the unwritten? rule of > "if you maintain some code you have the last word about it" > "if you maintain some code you have git write access" > "if someone disagrees about someone else maintaining then he better > volunteers himself to do a better job" > > Now, if you look at the people who left FFmpeg over the years, i > think in many if not most cases it involved prior conflicts with other > developers over the area they worked on. > so the idea of > "if you maintain some code you have the last word about it" > is IMO important, this doesnt strictly need a maintainers file of > course. > But many people work on what is fun for them, and while removing the > file or chageing its meaning doesnt directly change that, i think we > should be carefull to avoid creating a difference between the people > actively working on the code and the ones being in charge about the > code in question. I fundamentally disagree with this. Blind blocking was one of the largest frustrations that caused the creation of Libav. Haven't you learned anything? I don't think we've had this situation arise for a few years, but I certainly don't want anyone to think I'm OK with people blocking code just because they marked a box in MAINTAINERS first. It smells like patents. If technical arguments can't resolve a particular problem, then the problem likely isn't technical, and one random person's opinion certainly shouldn't be law (but a different law for each file). That's what the voting committee is for (so that at least it's somewhat consistent across the project). Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
