Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

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

> On Apr 11, 2021, at 5:24 PM, 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.

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).

> 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.

I've observed a parallel set of cases initiated by committers'
requests for feedback.  The dynamic is somewhat different; the
discussions are never held up due to a participant's technical
constraints, and they tend to be more open-ended.  Plus, the
"contributor morale" benefits [*] of reminders don't apply.

> 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

I've been thinking along similar lines myself and have found an
alternative taxonomy to be clarifying:

(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?

> 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.)

  [*]: https://producingoss.com/en/share-management.html#patch-manager
       "The project might miss out on a useful patch this way, and
       there are other harmful side effects as well: it is discouraging
       to the author, who invested work in the patch, and it is
       discouraging to others considering writing patches."


Messages sorted by: Reverse Date, Date, Thread, Author