From owner-svn-src-all@freebsd.org Tue Apr 2 04:10:44 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 CCCFC1553CA0 for ; Tue, 2 Apr 2019 04:10:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CAB970FF3 for ; Tue, 2 Apr 2019 04:10:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id s15so13711045qtn.3 for ; Mon, 01 Apr 2019 21:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VflQl63TTm+XTGyAWOb0zH5kOP9nRAgbl8WHRCV6LMA=; b=r76EDxVarOqj/O5Z15+LwIuwHxNQRwyZscdpoLPt/ZklaMzT0mZyhxsmPffbDNVzVi iqzUdf+FqqcAkF1y3WjriPJRHB0aS91fvEuEHixavEzz3gFJnVpANEeZFL5Zcks9z7qN j4rxRzelUs5Es/24Pm7xIMscKR3qpV/Ga8oXG9anmjfPyZFSI0KmGXNQdyh0PRqesE16 YXlgxma/kWeif+tTcprZjOMjXD8I0w+fqb9opC7SzqLIj6ToZsRASAKXVZFO8GtRvcvf aSqCsLe696b1JWoBNCjhk0riiS1oKGNZNRJ/9dOvu19iJ8uBea+BVBTMmcbrvqz9iHON ceSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VflQl63TTm+XTGyAWOb0zH5kOP9nRAgbl8WHRCV6LMA=; b=UQSPoAYE5ck4LROtnFfDpfClLh/9JJbbN36YCq8J+CfEOMcEWzOw/jLaENQdlbr/bg Z1FNh1ZV/lH9MOVG8o+55cXilMygIHSisPNnBaTfm6tykJ2oE5PsV5E2X6LJ27ip2eeE kVPtJ9pqp4eIyGVF7ZWtYQ46iTobo8XqzA3gavw9vMK0/M6Po3FREAZHLhBH38YbniEI flqS/J9dMlL2TPHfCPHSQtB5PjWqmyy5T0fOhmf3aTcSHFmn3+ZrUbk4AAX7tGHOU59A Rpu9weQPEeLTCvE4Te6HW1ngku4ZLhUKuPI9VDsXLKB6gCCeQcbO99BL2FDd9jgF+Csr wIaw== X-Gm-Message-State: APjAAAU9sZeFnaluDHbEjSAyNTY/cARkbyC9zbGxMpgMsYGc6aNg3/+6 b8o1an8Yf9FifvqNj6gEsE1Gj8cuZ601iQ8T0fCx1Q== X-Google-Smtp-Source: APXvYqw5cDyNAmYGynYkFhd3HEqN1A5UaVcBsWD6Js1A1mTYE33eKv4kphx0Lxau6hhMc185xF/pjLXjpWISxa0EGDs= X-Received: by 2002:ac8:3328:: with SMTP id t37mr58978482qta.246.1554178242887; Mon, 01 Apr 2019 21:10:42 -0700 (PDT) MIME-Version: 1.0 References: <201904020345.x323jKM2018935@gndrsh.dnsmgr.net> In-Reply-To: <201904020345.x323jKM2018935@gndrsh.dnsmgr.net> From: Warner Losh Date: Mon, 1 Apr 2019 22:10:31 -0600 Message-ID: Subject: Re: svn commit: r345786 - svnadmin/conf To: "Rodney W. Grimes" Cc: Joseph Mingrone , src-committers , svn-src-all , svn-src-svnadmin@freebsd.org X-Rspamd-Queue-Id: 6CAB970FF3 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.969,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 04:10:44 -0000 On Mon, Apr 1, 2019, 9:45 PM Rodney W. Grimes wrote: > > 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 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 >