Zsh Mailing List Archive
Messages sorted by:
Re: Patch bumping (was Re: Feature Patch: Use completion to view parameter values)
[Marlon: Your quote attribution line is indented one more level than is
Marlon wrote on Mon, Apr 12, 2021 at 11:18:43 +0300:
> On 12 Apr 2021, at 00:24, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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.
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.
Messages sorted by: