From owner-svn-src-all@freebsd.org Tue Sep 3 14:06:23 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 647E0DC2C7; Tue, 3 Sep 2019 14:06:04 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N7yz50fqz4P8P; Tue, 3 Sep 2019 14:06:03 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 749571A05C; Tue, 3 Sep 2019 14:05:56 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 73DB71ABC6; Tue, 2 Apr 2019 03:45:27 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FEB8703FC; Tue, 2 Apr 2019 03:45:27 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1D62A1ABC4; Tue, 2 Apr 2019 03:45:27 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id AA9311ABC0; 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 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 Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 2FEB8703FC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: , Date: Tue, 03 Sep 2019 14:06:24 -0000 X-Original-Date: Mon, 1 Apr 2019 20:45:20 -0700 (PDT) X-List-Received-Date: Tue, 03 Sep 2019 14:06:24 -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