From owner-svn-src-svnadmin@freebsd.org Tue Sep 3 14:06:05 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 71719DC2D3; Tue, 3 Sep 2019 14:06:04 +0000 (UTC) (envelope-from yuripv@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 46N7yz56g4z4P8W; Tue, 3 Sep 2019 14:06:03 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 908AC1A068; 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 C725B1B667; Tue, 2 Apr 2019 04:38:53 +0000 (UTC) (envelope-from owner-src-committers@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 280B971FD6; Tue, 2 Apr 2019 04:38:53 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 0E4E61B62D; Tue, 2 Apr 2019 04:38:53 +0000 (UTC) Delivered-To: src-committers@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 2A1391B629 for ; Tue, 2 Apr 2019 04:38:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 C966A71FCE for ; Tue, 2 Apr 2019 04:38:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id z76so7090419qkb.12 for ; Mon, 01 Apr 2019 21:38:49 -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=SU3CD9NLlVRe1iWx2QmsRCoeBWy/rZ6Zq3XVcW5Tt4Y=; b=V2a/inGAlhhsBX/lLcy3YmgytcgRvjcIUPvNj6rOoK5wpJryI9OKXDKDSCUQtUhjP6 pg2Yly22knhsJBw6dcpPXrlGhkLotaIg41bfGRdiBCmKn2fE5PdGe0uvCZvh33FUSaTi KSs3ECXYXSh/eSqnx2fwKhyVrYF5zHVJSLxFliSJ5nKK4xhegB1wJMWOMyjP45SgubcV fL0SLvlX/P+jYTOU8bcYR83DnQgqqi5YE1iSSFNjjDKooBlK34kCy6VKGl3544MaO1VQ PRh++UnlLIj4UycPxWhhTEjeaJa70AGgu5zYbcIe37KQ2Lw9R2oGOpX+5VCWxbXI77vG xTVQ== 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=SU3CD9NLlVRe1iWx2QmsRCoeBWy/rZ6Zq3XVcW5Tt4Y=; b=oAeYK3tDjeALZvlHuK1fNWK7Xt2pS8dsH/TSOjFWHa3kwxYutpIYuVAQ2FuZ9cB/qC hezQRgRzx/RAyiSgK9l0SraMmYluPi8vUe5ecTA2aj7aUDU0Tl/Do/y+eZX0kFMrvTQX z6RdDrNjB9EquY+raehV+SGmhP5mSM66kay44zpPsHcwmeR1Zhhx0uhecsaRlNM+vkN5 WxItHdYYsPToJeaf0a/fjmBpEg7Wp+Xmbvi8BdZ72c9FvmkzcPAOPK7joJ+y2Hucyxef 67mGBQXG2/kR6R9ny9UKllv10ehAX9Zn68llO8XK+Krc/i0jUJ1nIXDVZmmaI0XLSwQ1 K45g== X-Gm-Message-State: APjAAAVR7rRuuzM0v4KIMmu482FWQ1hheoB0KgwITiWHswDCCzp280/o ngiNtiN/EV50pgocVGib+6NfAYyp4dKs3b3fJQJjTQ== X-Google-Smtp-Source: APXvYqyf5NkKrLpPwwEKiTCM5uad2bMEKA7Vg92MmEY6RjVOESZePUV3xnXQ15fQo+quhPBdBiwjWfXn24tGcrrPgaA= X-Received: by 2002:a37:9a54:: with SMTP id c81mr43937488qke.113.1554179929149; Mon, 01 Apr 2019 21:38:49 -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: 280B971FD6 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_SHORT(-0.96)[-0.956,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:05 -0000 X-Original-Date: Mon, 1 Apr 2019 22:38:37 -0600 X-List-Received-Date: Tue, 03 Sep 2019 14:06:05 -0000 Missed part of this the first time... 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 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. > Yup. We delayed it, but it turned out that it came together fast. > 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? > We don't track that. We can reap them. It's just that we need to try to get a definitive response a little harder. The process is already a months long thing, so there is time... The whole vendor things just raises a huge can of worms. > Why? We usually give them out to vendors that have a relationship to the project long term, but whose staff rotates in and out. A little extra care hardly opens a can of worms. In this case, I knew the mentor was one who fostered vendor relationships in reviewing the changes. That made me realize I should ask about it. When the checklist idea was put forward I realized the ad hoc system should have a more details written down. > 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". > We've moved to teams to support hats and also to work problems. Those people shouldn't be timing out, in general, so checking into what they had been doing seems prudent. We may want to retire them from the so team. Or maybe not if they are the active secretary... Warner > 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 >