All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Weijie Yuan <wy@wyuan.org>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v3 2/2] doc: advise batching patch rerolls
Date: Wed, 24 Jun 2026 13:46:59 +0200	[thread overview]
Message-ID: <ajvDsy1qVCZoqiCu@pks.im> (raw)
In-Reply-To: <e1050a6ef5e26299b2c6d9743067fe3d7f4f8071.1782028813.git.wy@wyuan.org>

On Sun, Jun 21, 2026 at 04:05:34PM +0800, Weijie Yuan wrote:
> diff --git a/Documentation/MyFirstContribution.adoc b/Documentation/MyFirstContribution.adoc
> index 00704ab91e..35105bc3b4 100644
> --- a/Documentation/MyFirstContribution.adoc
> +++ b/Documentation/MyFirstContribution.adoc
> @@ -1330,6 +1330,28 @@ previous one" patches over 2 days), reviewers would strongly prefer if a
>  single polished version came 2 days later instead, and that version with
>  fewer mistakes were the only one they would need to review.
>  
> +This consideration applies not only when going from the initial patch to v2,
> +but also to later iterations of the same series. There is no fixed rule for how
> +long to wait before sending a new version. A useful default is to send at most
> +one new version of the same patch series per day. This gives multiple reviewers
> +time to comment, gives reviewers across time zones a fair chance to
> +participate, lets you batch feedback together, and gives you time to think
> +through the comments you received. Knowing that you should not immediately send
> +another version also encourages you to review the patches more carefully before
> +sending them, catch small mistakes such as typos and off-by-one errors
> +yourself, and let reviewers spend more of their attention on design,
> +algorithms, and other substantial issues.
> +
> +The right timing depends on the topic and the feedback. Larger series usually
> +need more review time. If the only comments so far are minor, such as typo
> +fixes, it often makes sense to wait a little longer in case deeper reviews are
> +still coming. If the comments call for substantial rework, do not rush out an
> +updated version before you have reviewed the larger changes carefully. Instead,
> +reply to the review that prompted the rewrite, say that you are preparing a
> +substantial rework, and mention which parts of the current series will become
> +obsolete so reviewers can avoid spending time on them until the updated series
> +is ready.

Makes sense.

Patrick

  reply	other threads:[~2026-06-24 11:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-13 14:08 [RFC PATCH 0/2] doc: clarify review replies and reroll timing Weijie Yuan
2026-06-13 14:08 ` [RFC PATCH 1/2] doc: encourage review replies before rerolling Weijie Yuan
2026-06-15 13:17   ` Patrick Steinhardt
2026-06-15 14:35     ` Weijie Yuan
2026-06-13 14:09 ` [RFC PATCH 2/2] doc: advise batching patch rerolls Weijie Yuan
2026-06-13 16:02   ` Junio C Hamano
2026-06-13 17:05     ` Weijie Yuan
2026-06-15 13:17       ` Patrick Steinhardt
2026-06-15 14:49         ` Weijie Yuan
2026-06-17 16:48 ` [PATCH v2 0/2] doc: clarify review replies and reroll timing Weijie Yuan
2026-06-17 16:50   ` [PATCH v2 1/2] doc: encourage review replies before rerolling Weijie Yuan
2026-06-17 16:51   ` [PATCH v2 2/2] doc: advise batching patch rerolls Weijie Yuan
2026-06-17 17:50     ` Junio C Hamano
2026-06-19 13:20       ` Weijie Yuan
2026-06-24 11:46         ` Patrick Steinhardt
2026-06-21  8:04   ` [PATCH v3 0/2] doc: clarify review replies and reroll timing Weijie Yuan
2026-06-21  8:05     ` [PATCH v3 1/2] doc: encourage review replies before rerolling Weijie Yuan
2026-06-21  8:05     ` [PATCH v3 2/2] doc: advise batching patch rerolls Weijie Yuan
2026-06-24 11:46       ` Patrick Steinhardt [this message]
2026-06-24 11:47     ` [PATCH v3 0/2] doc: clarify review replies and reroll timing Patrick Steinhardt

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=ajvDsy1qVCZoqiCu@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=wy@wyuan.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.