From owner-svn-src-svnadmin@freebsd.org Tue Sep 3 14:06:04 2019 Return-Path: Delivered-To: svn-src-svnadmin@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 40B9DDC2B1; 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 46N7yz4XPKz4P8D; Tue, 3 Sep 2019 14:06:03 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 853E41A062; 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 [IPv6:2610:1c1:1:606c::19:1]) (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 19DC01B1EE; Tue, 2 Apr 2019 04:10:47 +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 4D67E71004; Tue, 2 Apr 2019 04:10:46 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 140971B181; Tue, 2 Apr 2019 04:10:46 +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 B11DA1B17D for ; Tue, 2 Apr 2019 04:10:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 73CE970FF5 for ; Tue, 2 Apr 2019 04:10:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x830.google.com with SMTP id t28so13685201qte.6 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=buxClT/Xns5grY6/OOHmeW3fdodNZt1gdNfp/rwBBPPx1yq4BgD/tdDY9iq+4OeTLL CxhOqeCL12LaGPGjO+bivAOVXPFkExFUOwWL0F82aKNAn8XqkWceyLkIAa7m9KlE1HCr Hwa9pMyzq/qYHOiY7JCqCIKQu6/QZ6D6DFiiPZPRRCv7SXRtsbWSuQjtNtUaOAP4WPsz d+cjNdOQkvyoUAJ2zBwUBS3/oBIjrcnUZv0BLm3XUvg8gEqEhSAgrGD3ZPioc/dUYefz pxBFt0l9YzcMOPmUt/3o6h3z9am2RgRqjkmRJrHi+zQ1XoTj1DxaAHPYjY1HE1MlGkC9 BXkw== X-Gm-Message-State: APjAAAXHKY/ubMHCnz7aI13yz5M8MGco71ruCLmfnIBdCPuU2jfLWDev SlNh0+OvnJ6oh5Wv95sp2/mo1AZl+vcEZXIL5wuTkQ== 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 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 Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 4D67E71004 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.95)[-0.955,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-svnadmin@freebsd.org X-Mailman-Version: 2.1.29 List-Id: SVN commit messages for the admin / configuration tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:06:04 -0000 X-Original-Date: Mon, 1 Apr 2019 22:10:31 -0600 X-List-Received-Date: Tue, 03 Sep 2019 14:06:04 -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 >