mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Eric Sunshine <>
Cc: Felipe Contreras <>,
	Bagas Sanjaya <>,
	Dave Huseby <>,
	Git List <>,
	Christian Couder <>,
Subject: Re: [PATCH v2] Writing down mail list etiquette.
Date: Wed, 12 May 2021 23:36:02 +0900	[thread overview]
Message-ID: <xmqqbl9gf299.fsf@gitster.g> (raw)

Eric Sunshine <> writes:

> This has been my experience, as well. I've never sent a v6 with Junio
> as an explicit recipient, but which was otherwise identical to v5.

It mostly is because I've been too helpful than the written rule to
proactively pick up v5, before the participants of the discussion
explicitly reaches concensus that it is good enough.

In an ideal world, patches in areas that I do not have particular
interest in and that other reviewers with good taste are performing
good reviews, I should be able to keep myself completely out of the
picture, not involved in their review discussion in any way, and not
even having to monitor if the discussion reached some concensus, and
purely play a patch-monkey for such patches.  That, combined with
more reviewers with good tastes, would allow us to injest patches at
faster rate than we currently can.

> Another reason to avoid sending v6 which is identical to v5 is that it
> potentially wastes reviewer bandwidth.

As long as it is marked as "this is the final version that is
identical to the previous round, only difference from which is that
the collected reviewed-by and acked-by have been added", it would
not waste reviewer bandwidth.  The reviewers _should_ however notice
if it has questionable changes since the "previous round", in which
case their reviewed-by's may now be invalid, of course, though.

> The advice which seems to have triggered this particular discussion
> comes from Documentation/SubmittingPatches:
>     After the list reached a consensus that it is a good idea to
>     apply the patch, re-send it with "To:" set to the
>     maintainer{current-maintainer} and "cc:" the list{git-ml} for
>     inclusion.  This is especially relevant when the maintainer did
>     not heavily participate in the discussion and instead left the
>     review to trusted others.
> It's not the first time this advice has resulted in confusion. Perhaps
> now would a good time to retire it altogether, or at least rewrite it
> to mention the points you gave above about responding to "What's
> Cooking" or by sending a "ping" to the original patch email (which may
> result in Junio either picking up the patch or responding with an
> explanation as to why he didn't).

No, please do not put _more_ tasks on my plate.

The "send the final with everybody's concensus" is an ideal that
tries to reduce the maintainer bottleneck by distributing the work
of final validation.  I've been too helpful in this area in that I
have often been the one who does the "ping" ("What is the status of
this topic?"), but that would _not_ scale.  Anything that the party
with more numbers, namely the contributors, can do, we should farm
it out to them.

> Following the above SubmittingPatches paragraph is another which also
> seems to mislead people frequently:
>     Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:`
>     and `Tested-by:` lines as necessary to credit people who helped
>     your patch, and "cc:" them when sending such a final version for
>     inclusion.
> In fact, a submitter should almost never add a Reviewed-by: trailer
> because Reviewed-by: is explicitly given by a reviewer only when the
> reviewer is satisfied that the patch is merge-ready, in which case no
> more re-rolls are expected.

Yes, that is exactly why v6 that is identical to v5 that all
reviewers are happy with is useful.  It should be able to carry
reviewed-by's and acked-by's, reviewers can audit that there is no
forged or otherwise inappropriate reviewed-by's, without placing any
extra burden on the maintainer.


  parent reply	other threads:[~2021-05-12 14:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12  2:54 [PATCH v1] Writing down mail list etiquette Dave Huseby
2021-05-12  2:57 ` Dave Huseby
2021-05-12  6:25   ` Felipe Contreras
2021-05-12  3:18 ` Dave Huseby
2021-05-12  3:18   ` [PATCH v2] Writing down mail list etiquette Dave Huseby
2021-05-12  4:07     ` Bagas Sanjaya
2021-05-12  6:45       ` Felipe Contreras
2021-05-12  7:35         ` Eric Sunshine
2021-05-12  8:32           ` Felipe Contreras
2021-05-12 14:36           ` Junio C Hamano [this message]
2021-05-12  4:46     ` Junio C Hamano
2021-05-12  8:45     ` Ævar Arnfjörð Bjarmason
2021-05-12 23:34     ` [PATCH v3] doc: writing down Git mailing " Dave Huseby
2021-05-13  0:20       ` Junio C Hamano
2021-05-13 17:17         ` Dave Huseby
2021-05-13 20:04           ` Felipe Contreras
2021-05-13 21:11           ` Junio C Hamano
2021-05-13  4:06       ` Bagas Sanjaya
2021-05-13  6:34       ` Felipe Contreras
2021-05-13  7:01       ` Bagas Sanjaya
2021-06-09 17:36       ` Felipe Contreras
2021-06-18 20:43         ` Dave Huseby
2021-06-18 23:48           ` Felipe Contreras
2021-05-12 15:28   ` and... Re: [PATCH v1] Writing down mail " Philip Oakley
2021-05-12  6:21 ` Felipe Contreras

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:

  List information:

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

  git send-email \
    --in-reply-to=xmqqbl9gf299.fsf@gitster.g \ \ \ \ \ \ \ \ \

* 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

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 read-only IMAP folder(s) and NNTP newsgroup(s).