From owner-svn-src-svnadmin@freebsd.org Tue Apr 2 03:45:24 2019
Return-Path: <owner-svn-src-svnadmin@freebsd.org>
Delivered-To: svn-src-svnadmin@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" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <201904020345.x323jKM2018935@gndrsh.dnsmgr.net>
Subject: Re: svn commit: r345786 - svnadmin/conf
In-Reply-To: <CANCZdfpLs-7+DwhopKPp-14rC6owPwBq8_smDxUzRnup7R+aRw@mail.gmail.com>
To: Warner Losh <imp@bsdimp.com>
Date: Mon, 1 Apr 2019 20:45:20 -0700 (PDT)
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
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-svnadmin@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SVN commit messages for the admin / configuration tree
<svn-src-svnadmin.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-svnadmin>,
<mailto:svn-src-svnadmin-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-svnadmin/>
List-Post: <mailto:svn-src-svnadmin@freebsd.org>
List-Help: <mailto:svn-src-svnadmin-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-svnadmin>,
<mailto:svn-src-svnadmin-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 03:45:25 -0000
> 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