Date: Mon, 1 Apr 2019 22:10:31 -0600 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <rgrimes@freebsd.org> Cc: 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: <CANCZdfrtkEvJ8g4O_8x-X1uiR1AvZmpJskuzBQUKsTXUHxZ-KQ@mail.gmail.com> In-Reply-To: <201904020345.x323jKM2018935@gndrsh.dnsmgr.net> References: <CANCZdfpLs-7%2BDwhopKPp-14rC6owPwBq8_smDxUzRnup7R%2BaRw@mail.gmail.com> <201904020345.x323jKM2018935@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 1, 2019, 9:45 PM Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> wrote: > > 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 is new list. It's a great idea so I has Joseph create it. > 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. > Agreed. It is a separate issue even to the one you raised. Balls were dropped in the past. Checklists help stop that. The problem with some departures is that they are effective long before we realize it. The 6 month checkup is a backstop to deal with that in a more formal way, as well as giving us a chance to make sure the fit is good, there is still interest from the mentee, etc. Warner > > - 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?CANCZdfrtkEvJ8g4O_8x-X1uiR1AvZmpJskuzBQUKsTXUHxZ-KQ>