On Mon, Apr 1, 2019, 8:26 PM Rodney W. Grimes <free...@gndrsh.dnsmgr.net> wrote:
> > Warner Losh <i...@bsdimp.com> writes: > > > > > On Mon, Apr 1, 2019 at 7:15 PM Rodney W. Grimes < > free...@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 > rgri...@freebsd.org > _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
