zsh-workers
 help / color / mirror / code / Atom feed
From: "Lawrence Velázquez" <larryv@zsh.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org, Marlon Richert <marlon.richert@gmail.com>
Subject: Re: Patch bumping (was Re: Feature Patch: Use completion to view parameter values)
Date: Mon, 12 Apr 2021 22:47:50 -0400	[thread overview]
Message-ID: <447A0505-D429-4714-A225-994B61213973@zsh.org> (raw)
In-Reply-To: <CAH+w=7bVsc0XNMuGhU4SAv7ZLj1f3_5aT+SuUtmMbMGneVq+NQ@mail.gmail.com>

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

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


-- 
vq

  parent reply	other threads:[~2021-04-13  2:48 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-28 20:53 Feature Patch: Use completion to view parameter values Marlon Richert
2021-03-29  7:39 ` Daniel Shahaf
2021-03-29 11:55   ` Marlon Richert
2021-03-29 17:11     ` Daniel Shahaf
2021-03-29 17:20       ` Bart Schaefer
2021-03-29 18:14         ` Daniel Shahaf
2021-03-29 20:00           ` Marlon Richert
2021-03-29 20:05             ` Daniel Shahaf
2021-03-29 20:35               ` Marlon Richert
2021-04-01  4:28                 ` Marlon Richert
2021-04-01 18:40                   ` Daniel Shahaf
2021-04-02  0:50                 ` Oliver Kiddle
2021-04-10 20:20                   ` Lawrence Velázquez
2021-04-11 20:06                     ` Marlon Richert
2021-04-11 21:24                     ` Patch bumping (was Re: Feature Patch: Use completion to view parameter values) Bart Schaefer
2021-04-12  8:18                       ` Marlon
2021-04-13 12:32                         ` Daniel Shahaf
2021-04-13 18:08                           ` Lawrence Velázquez
2021-04-15  9:39                             ` [META] Tone of voice / Writing style in patch reviews (was Re: Patch bumping) Marlon
2021-04-15 10:33                               ` zeurkous
2021-04-13 13:35                         ` Patch bumping (was Re: Feature Patch: Use completion to view parameter values) Daniel Shahaf
2021-04-13 21:31                           ` Lawrence Velázquez
2021-04-13 21:50                             ` Bart Schaefer
2021-04-14 12:52                             ` Daniel Shahaf
2021-04-13  2:47                       ` Lawrence Velázquez [this message]
2021-04-12 20:22                   ` Feature Patch: Use completion to view parameter values Marlon
2021-04-12 21:49                     ` Bart Schaefer
2021-04-13  4:50                       ` Marlon Richert
2021-03-30  5:41           ` Mikael Magnusson
2021-03-31 22:55             ` Daniel Shahaf
2021-03-31 23:03               ` Daniel Shahaf
2021-03-29 20:10         ` Peter Stephenson
2021-03-29 11:48 ` Mikael Magnusson
2021-03-29 12:06   ` Marlon Richert
2021-03-29 12:07     ` Marlon Richert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=447A0505-D429-4714-A225-994B61213973@zsh.org \
    --to=larryv@zsh.org \
    --cc=marlon.richert@gmail.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).