Git development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox