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

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

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:
> > 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.
⋮
> > 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.
> 
> I would suggest the following minimum wait times before bumping:
> 
> * To remind about an unresolved patch (not yet reviewed, not yet responded to by author after review, not yet accepted/rejected/committed, etc.):
>   * security issues: 2 days
>   * critical bug fixes: 1 week
>   * all other patches: 2 weeks
> * Everything else: 1 month

I'm not sure what cases fall into "etc." and what cases fall into
"everything else", nor what would a "critical" bugfix be.

Lawrence Velázquez wrote on Mon, Apr 12, 2021 at 22:47:50 -0400:
> On Apr 11, 2021, at 5:24 PM, 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.
> 
> Certainly!  I've been combing the lists every Saturday afternoon/evening
> UTC and uniformly bumping recent discussions that have been inactive for
> more than five days (to loop in the preceding weekend).

> 

⋮

> (A) A noncommitter is waiting on a committer (#1, #2, #3).
> (B) A committer is waiting on a noncommitter (#4).
> (C) A committer is waiting on other committers (the parallel cases).
> 
> As the reason the "patch manager" role exists [*], group A should
> be handled expeditiously, while groups B and C can wait.  (This
> classification reflects how meddlesome I feel when I send reminders.)
> 
> I think a threshold of 1-2 weeks remains appropriate for A, but
> perhaps ~1 month would better suit B and C?

How would differential delays affect your workflow?  A uniform criterion
(such as "Thread has been dormant for >5 days") should be easier to apply.

Regarding your taxonomy, would it be accurate to say that in cases
A and B a submitted patch is awaiting resolution, whereas in case C it's
generally a design question that's awaiting resolution?  In A+B the
person in question is the patch submitter; in C the person in question
is probably a regular developer.

(Aside: Note the terminology: "developer", not "committer", since in
general, distinctions between people who do and don't have commit access
shouldn't be made, except when it's necessary to actually invoke «git
push».¹)

Regarding the magic numbers, I think one month is too long for case B
(cf. my remarks today in workers/48526).  We don't want to bump _too_
soon either, but I'd aim for something on the order of a week (for the
first ping, again as per 48526).  "Once a week for patches ≥6 days old"
achieves that, as would, say, "at least 48 weekend hours and at least
72 weekday hours".

No comment from me on case C.

Cheers,

Daniel

> > unless the patch is fixing a serious bug or security issue.
> 
> Do you think we need to prescribe a standard for these?  They seem
> pretty rare, and committers are unlikely to let them drop through
> the cracks.  My initial inclination is to leave them to committers'
> discretion.  (I'm not privy to zsh-security@ anyway.)