svn commit: r345786 - svnadmin/conf
imp at bsdimp.com
Tue Apr 2 03:29:48 UTC 2019
On Mon, Apr 1, 2019, 8:26 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
> > 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
> > 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
> > 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.
> - If the developer whose bit to be removed is a mentee, remove the
> > from the mentors file.
> > - Remove the developer from the access file.
> > --
> > Joseph
> Rod Grimes
> rgrimes at freebsd.org
More information about the svn-src-svnadmin