mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eric Sunshine <>
To: Felipe Contreras <>
Cc: Bagas Sanjaya <>,
	Dave Huseby <>,
	Git List <>,
	Christian Couder <>,
	Junio C Hamano <>,
Subject: Re: [PATCH v2] Writing down mail list etiquette.
Date: Wed, 12 May 2021 03:35:32 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <609b797a818bb_6d897208ce@natae.notmuch>

On Wed, May 12, 2021 at 2:45 AM Felipe Contreras
<> wrote:
> Bagas Sanjaya wrote:
> > In practice, the maintainer could instead merged v5 (without having me to
> > send v6 [final]), because v5 is merge-ready in absence of maintainer's
> > email address in either To: or Cc:.
> Generally you don't need to worry about this, that's Junio's job. If
> your patch is ready, Junio will merge it... But not always.
> So no, you don't need to send v6, Junio will pick v5. If he doesn't,
> it's most likely because it slipped through the cracks, and you can see
> that in the next "What's cooking in git.git".
> If you don't see your merge-ready patch series in "what's cooking", then
> by all means send it again as v6, or reply to the "what's cooking" or
> something. But generally there's no point in sending a v6 identical to a
> v5.
> But if you already sent a v5 that is is merge-ready, there's no need
> to send an identical v6.
> All these suggestions are of course based on my own experience. Others
> might have different experiences.

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.

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

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

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

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. Instead, these particular trailers are
almost always added by Junio based upon reviewer responses he sees
when picking up a patch. So, it may be time, too, either to remove
this paragraph or to revise it to mention other trailers more
appropriate for use by the patch submitter, such as Helped-by:,
Suggested-by:, perhaps Co-authored-by:, etc.

  reply	other threads:[~2021-05-12  7:35 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 [this message]
2021-05-12  8:32           ` Felipe Contreras
2021-05-12 14:36           ` Junio C Hamano
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 \ \ \ \ \ \ \ \ \ \

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