Re: [PATCH v2] Writing down mail list etiquette.

From: Eric Sunshine <sunshine@sunshineco.com>
Date: May 12, 2021, 07:35 UTC
Message-ID: <CAPig+cQvnsRe0fdPaBe9hJ4LbPFmHmGVNdiGYLqi2JM7A5GmjA@mail.gmail.com>
In-Reply-To: <609b797a818bb_6d897208ce@natae.notmuch>

On Wed, May 12, 2021 at 2:45 AM Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 22 quoted lines

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