svn commit: r345786 - svnadmin/conf

[Warner Losh]

Missed part of this the first time...

On Mon, Apr 1, 2019, 9:45 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
wrote:

> > On Mon, Apr 1, 2019, 8:26 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net
> >
> > wrote:
> >
> > > > Warner Losh <imp at bsdimp.com> writes:
> > > >
> > > > > On Mon, Apr 1, 2019 at 7:15 PM Rodney W. Grimes <
> > > freebsd at 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.
>

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 at freebsd.org
> --
> Rod Grimes rgrimes at freebsd.org
>