[FFmpeg-devel] [RFC] MAINTAINERS cleanup

Michael Niedermayer michael at niedermayer.cc
Sun Jun 12 16:17:17 CEST 2016


On Sun, Jun 12, 2016 at 07:57:03AM -0400, Ronald S. Bultje wrote:
> 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 <
> michael at 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.

wait wait wait, theres something very very VERY different from what
that list should be and what you say

A maintainers job is to maintain code, its his job to get things done
and solved and implemented and fixed and reviewed (within normal
limits of available time and so on)
In that it could be that he rarely askes for a complex patch to be
on hold for a week to have more time to review it or to reject a patch
that is bad with a clear explanation what is bad and how to make it
good.
OTOH sitting there and just rejecting and blocking is not maintaining
such maintainers should resign and let others take over. Because they
arent doing the job and likely by existence of blocked patches there
are others who do care about things.

Git kind of makes this also alot easier to resolve than svn
with svn you could end with 2 people like this
A says this is wrong i wont accept it
B says this is right iam happy to take over maintaince of the file
now with svn you are screwed if this cannot be condensed into a
argument that is clear and understandable. One of the 2 being much
better at argumentation and flaming might even get people to pick
wrong.
WIth git let both maintain the code for a few month in their own
git tree. Then check which works better. thats not so easy to argue
away and safes alot of flaming time on top. (even without a maintainers
file this would make sense)



> 
> 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).

lets look at an actual recent problem
the multithread + hwaccel check which hardfailed

There was no maintainer really who could make a decission
The vote comitee did not do anything
videolan added a check to basically stop working with FFmpeg
and that whole blocked and delayed the release so that debian now
contains an old FFmpeg 

Had there been a maintainer he could have made a decission to break
this string of events earlier even if there was opposition
The vote comitee could theoretically have done it too but in fact this
process didnt even start


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160612/ccf6a194/attachment.sig>


More information about the ffmpeg-devel mailing list