svn commit: r330972 - stable/11/share/misc

[Rodney W. Grimes]

> On Thu, 2018-03-15 at 10:52 -0500, Justin Hibbits wrote:
> > On Thu, Mar 15, 2018 at 10:46 AM, Ian Lepore <ian at freebsd.org> wrote:
> > > 
> > > I agree completely with all of this.??It bothers me how many
> > > committers
> > > have the attitude that handling MFCs is not part of being a
> > > committer.
> > Never attribute to arrogance that which can adequately be explained
> > by
> > sheer laziness ;)
> > 
> > - Justin (guilty of marking changes as MFC after, and ignoring them
> > for far too long)
> > 
> 
> Laziness and procrastination I understand -- I own a lovely glass house
> in that neighborhood. ?I tend to put off MFCs for way too long then
> every few months have to spend a whole weekend catching up.

MFC: 1 week (by pool|self)	#defaults to self if missing

There is already a very nice tracking tool for outstanding MFC's,
if we added a bit of smarts in its parser, and created a pool of
MFC commiters (Eitan seems to have started one :-)) those who
do not want to do there own MFC work could pass the hat.

There is the issue that if sizeof(pool) gets to small things
shall surely fall off the end.  Perhaps at 2 x the timeout
on the MFC send a reminder back to the orignal commiter stating
the MFC has not happened and is now at 2x timeout?

I am guessing, but not certain, eadler is working off a list
from svn mergeinfo --show-revs eligible, having that list
updated/annoted with "Do note merge: reason" would help the
@pool above, and also help with when things are marked MFC,
but found later they should not be.  

Also, I know it has pitfalls and mistakes are gona happen,
but I feel a MFC: {never,breaks abi,ugly hack} marking would
also help the project with some of this.

-- 
Rod Grimes                                                 rgrimes at freebsd.org