Date: Mon, 1 Apr 2019 20:45:20 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Joseph Mingrone <jrm@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-svnadmin@freebsd.org Subject: Re: svn commit: r345786 - svnadmin/conf Message-ID: <201904020345.x323jKM2018935@gndrsh.dnsmgr.net> In-Reply-To: <CANCZdfpLs-7%2BDwhopKPp-14rC6owPwBq8_smDxUzRnup7R%2BaRw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Apr 1, 2019, 8:26 PM Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> > wrote: > > > > Warner Losh <imp@bsdimp.com> writes: > > > > > > > On Mon, Apr 1, 2019 at 7:15 PM Rodney W. Grimes < > > freebsd@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. I am confused. Is this a new list or a list that has existed for some time? > 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. That is another issue, not the issue I raise above. My concern is that mentors may not be responsive to a mentee, and that needs a clear path for the mentee to take action on. Aka neel has been gone for a long long time, and Grehan has been gone for months, yet we are just now picking up a new mentor for Anish. That preferable would of happened within days of Grehan leaving. > > - 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. That was this time, that may not always be the case, lets solve the problem and document that solution so that the future is handled. > 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. Do we even track vendor bits, do we have any action plan for vendor bits when that person leaves a vendor, should there be an action, should it be possible for a vendor to reap the bit? The whole vendor things just raises a huge can of worms. > We also need to check to see if the volunteer is in any groups as well. committer? Yes, defanitly, and that should include more than hat's, which is what I think you meant by "groups". > 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@freebsd.org -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201904020345.x323jKM2018935>