svn commit: r345786 - svnadmin/conf

[Warner Losh]

On Mon, Apr 1, 2019, 8:26 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
wrote:

> > Warner Losh <imp at bsdimp.com> writes:
> >
> > > On Mon, Apr 1, 2019 at 7:15 PM Rodney W. Grimes <
> freebsd at gndrsh.dnsmgr.net>
> > > wrote:
> >
> > >> > Author: jrm (ports committer)
> > >> > Date: Mon Apr  1 21:34:58 2019
> > >> > New Revision: 345786
> > >> > URL: https://svnweb.freebsd.org/changeset/base/345786
> >
> > >> > Log:
> > >> >   Set jhb@ as new mentor to anish@
> >
> > >> >   Approved by:        core (brooks, seanc)
> > >> >   Differential Revision:      https://reviews.freebsd.org/D19782
> >
> > >> Can we please have a check list that when someones
> > >> commit bit is reaped, or steps away from the project
> > >> for more than N days, N being something rather small
> > >> given the context here, that includes the item:
> >
> > >>         x)  Is this person a mentor of anyone?
> >
> >
> > > Great idea...  Joseph will put one together based on this round of
> > > retirement...
> >
> > <snip>
> >
> > This is the current checklist:
>
> Should this be a publically visible check list?  If I had know of it
> I would not of even raised an issue.
>

That's the idea.

This only handles the reap situation, which takes too long to leave
> a menteee hanging, they are gone long before you get to this point.
>
> Perhaps adding an item to the new committers guide:
>         If a mentor should go unresponsive or seem to be inactive
>         in the project you should contact core@ asking for remediation or
>         reassignment of that mentor.
>

We've talked about a 6 month timeout for new committees. Nothing definite.

> - Check for idle developers using: idle-commit-bits.pl base 18
> >
> > - Source bits are taken in for safekeeping after three consecutive
> emails about
> >   reaping go unanswered, or if the developer in question confirms that
> the bit
> >   can be taken in.  The email-to-idlers.pl script can be used to send
> warning
> >   emails, but Ren? is currently taking care of this job.
> >
> > - Once it has been established that a bit is to be taken in, first check
> the
> >   mentors file to see if this developer is a mentor.  If so, a new
> mentor must
> >   be found before the bit is taken in.
>
> I see no reason for delaying the reap action, that just further leaves
> the mentee in limbo.  Perhaps:
> Once it has been established that a bit is to be take in, first check the
> mentors file to see if this developer is a mentor.  If so, create a core@
> action item to find them a replacement, inform the mentee that this action
> item has been created, asking them if they have any input as to who might
> be a good canidate.  Reassign them to core@ in the mentors file.
>

We were able to find someone in 10ish minutes... there was no delay... it
was one of the pre-commit activities.

There was one more: is this person a vendor committer? Is so, we do need to
do additional checks to help vendor relationships. Normally, these are
managed well, but if we get to time out for a vendor committer, that
suggests something may have broken down. At one point the vendor wanted a
fast path into the project.

We also need to check to see if the volunteer is in any groups as well.

Warner

> - If the developer whose bit to be removed is a mentee, remove the
> developer
> >   from the mentors file.
> >
> > - Remove the developer from the access file.
> >
> > --
> > Joseph
> --
> Rod Grimes
> rgrimes at freebsd.org
>