git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 12, 2021, 08:32 UTC
Message-ID
<609b928aeb66e_6e4e9208b7@natae.notmuch>
In-Reply-To
<CAPig+cQvnsRe0fdPaBe9hJ4LbPFmHmGVNdiGYLqi2JM7A5GmjA@mail.gmail.com>
Eric Sunshine wrote:
Show 47 quoted lines
> On Wed, May 12, 2021 at 2:45 AM Felipe Contreras
> <felipe.contreras@gmail.com> 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).
Agreed.

(Although sometimes a patch series of mine has actually received consensus, and yet for some reason Junio does not pick it up. Except in that case sending a v6 certainly would not improve the situation. Not sure if that's specific to me though.)

Show 14 quoted lines
> 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.
I don't fully agree with that comment.

At least me personally if I see people acking v5, I add them to v6 as Reviewed-By.

I'm not sure if that makes any difference to Junio, but that's what I've historically done.

Cheers.
-- 
Felipe Contreras
Previous: Eric SunshineNext: Junio C Hamano
Message 9 of 25 in “Writing down mail list etiquette.”
  1. Writing down mail list etiquette.Dave Huseby, May 12, 2021
  2. Dave HusebyMay 12, 2021
  3. Felipe ContrerasMay 12, 2021
  4. Dave Huseby, May 12, 2021
  5. Writing down mail list etiquette.Dave Huseby, May 12, 2021
  6. Bagas SanjayaMay 12, 2021
  7. Felipe ContrerasMay 12, 2021
  8. Eric SunshineMay 12, 2021
  9. Felipe ContrerasMay 12, 2021
  10. Junio C HamanoMay 12, 2021
  11. Junio C HamanoMay 12, 2021
  12. Ævar Arnfjörð BjarmasonMay 12, 2021
  13. doc: writing down Git mailing list etiquetteDave Huseby, May 12, 2021
  14. Junio C HamanoMay 13, 2021
  15. Dave HusebyMay 13, 2021
  16. Felipe ContrerasMay 13, 2021
  17. Junio C HamanoMay 13, 2021
  18. Bagas SanjayaMay 13, 2021
  19. Felipe ContrerasMay 13, 2021
  20. Bagas SanjayaMay 13, 2021
  21. Felipe ContrerasJun 9, 2021
  22. Dave HusebyJun 18, 2021
  23. Felipe ContrerasJun 18, 2021
  24. and... Re: [PATCH v1] Writing down mail list etiquette.Philip Oakley, May 12, 2021
  25. Felipe ContrerasMay 12, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.