From owner-svn-src-all@freebsd.org Tue Apr 2 03:45:24 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAFBF15533E6; Tue, 2 Apr 2019 03:45:24 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DC62703F7; Tue, 2 Apr 2019 03:45:24 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x323jKV2018936; Mon, 1 Apr 2019 20:45:20 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x323jKM2018935; Mon, 1 Apr 2019 20:45:20 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201904020345.x323jKM2018935@gndrsh.dnsmgr.net> Subject: Re: svn commit: r345786 - svnadmin/conf In-Reply-To: To: Warner Losh Date: Mon, 1 Apr 2019 20:45:20 -0700 (PDT) CC: "Rodney W. Grimes" , Joseph Mingrone , src-committers , svn-src-all , svn-src-svnadmin@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 2DC62703F7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.956,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 03:45:25 -0000 > On Mon, Apr 1, 2019, 8:26 PM Rodney W. Grimes > wrote: > > > > Warner Losh 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... > > > > > > > > > > > > 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