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
next prev parent 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