svn commit: r347477 - head/sys/kern

[Rodney W. Grimes]

> Hi;
> 
> On 10/05/2019 23:57, Doug Moore wrote:
> > With mentor approval, I commit r347469.? I start getting email about
> > jenkins failure to build for several architectures on account of the
> > _Generic() construct I introduced in that change.
> >
> > I whip up a patch to undo that part of r347469, and ask for mentor
> > approval.? Meanwhile, mentor authorizes me in email to revert r347469.
> >
> > I try apply applying the fix-patch, and get email that it was rejected
> > for lack of reviewer.? In retrospect, it seems to have been committed
> > anyway as r347472.
> >
> > Thinking that things are still broken, I do what my mentor pre-approved
> > earlier and revert back to before r347469.? A patch to redo r347469,
> > without _Generic(), awaits mentor approval.
> 
> Ugh...? a rather elegant interaction ;)
> 
> > I realize that breaking the build and then committing without mentor
> > approval in my first week as committer isn't a good beginning.?? Sorry
> > about that.
> 
> It's probably not official policy but I would think you don't need 
> mentor approval to revert a change, assuming things return to the 
> pre-commit state, especially if it broke the build.

Perhaps this also should be added to the committers guide of
explaining what and when you need mentor approval, ie I would
consider a revert of a commit that was approved to have
mentor (implicit) type status.

It should also document that mentors can grant mentee's implicit
commit rights, like phk/bde have for all my MFC's, we (I asked,
they granted) agreed that if I had approval to commit it to head
I did not need to ask them for each merge to be approved.  This
one should probably be best a per mentor/mentee type agreement.

> Pedro.
-- 
Rod Grimes                                                 rgrimes at freebsd.org