Re: Patch bumping (was Re: Feature Patch: Use completion to view parameter values)

[Daniel Shahaf <d.s@daniel.shahaf.name>]

[Marlon: Your quote attribution line is indented one more level than is
conventional]

Marlon wrote on Mon, Apr 12, 2021 at 11:18:43 +0300:
> On 12 Apr 2021, at 00:24, Bart Schaefer <schaefer@brasslantern.com> wrote:
> > With appreciation for Lawrence's efforts, I'd respectfully request
> > that the criteria for when to send a "bump" become a matter of record.
> > 
> > There seem to me to be these cases:
> > 
> > 1.  The patch has never been reviewed or discussed.
> > 2.  The patch was reviewed and is acceptable, but was never applied.
> > 3.  There was a discussion, but it ended without resolution.
> > 4.  The patch was referred back to the author after review or discussion.
> > 
> > There is room for subjective interpretation of "is acceptable".  A
> > possible resolution of #2 is that the patch is rejected after all
> > (perhaps it has become obsolete in the meantime).
> > 
> > I mention this mostly because I think the useful elapsed time before
> > "bumping" might be different in each case.  In particular #4 seems
> > like it could be left considerably longer, unless the patch is fixing
> > a serious bug or security issue.
> > 
> > Thoughts?

Leaving #4 "considerably longer" would decrease temporal locality in the
patch authors' brains, would reap less "the project noticed my lack of
response" benefits (cf.
https://producingoss.com/en/managing-participants.html#delegation-followup),
and would be more likely to find the patch author busy with other things
and unable to follow up and post a revised patch.

You don't actually say what benefits you seek to attain.  Is it about,
say, bumps that are replies to previous bumps?  If so, I'd propose, say:

- A bump that is a reply to a non-bump should be sent with delay X.

- A bump that is a reply to a bump should be sent with delay Y.

- A bump that is a reply to a bump that is a reply to a bump should be
  sent with delay Z and added to git (as proposed in workers/48303).

- A bump (that is a reply to a bump)³ should not be sent.

(Feel free to read "should" and "should not" in their rfc2119 senses.)

> Additionally, it would be helpful if committers remember to inform us
> when a when a patch has been accepted/rejected/applied,

This would be helpful for other other reasons too:

- It would let the patch submitter know their patch has been accepted.
  (Simply committing the patch to git without replying to it might leave
  the patch submitter think they were ignored.)

- It would make it easier for other committers to skip PATCH threads
  that have already been handled.

> to avoid unnecessary bumps.

Cheers,

Daniel