On the nature of cover letters [WAS Re: [PATCH 0/6] Create Git/Packet.pm]

On Mon, Oct 30, 2017 at 11:08 AM, Jeff King [off-list ref] wrote:

On Mon, Oct 23, 2017 at 01:26:41PM +0100, Philip Oakley wrote:

quoted

quoted

Totally offtopic, but is it only me who finds these "section
headers" in cover letters from some people irritating and/or
jarring?

Personally I find that, for significant patch series, that clearly breaking
out these distinct sections is of advantage. At this stage (the very first
patch 0/n) there is no specific conversation, so the subject line is a short
'hello' to the topic, and then the contributor is (it is to be hoped)
setting out their proposal in a clear manner.

So I do like these headings for larger series, though there is some
judgement to be made as to when the subject line alone is sufficient.

I can live with fancily-formatted cover letters. BUT. I would say if
your cover letter is getting quite long, you might consider whether some
of its content ought to be going elsewhere (either into commit messages
themselves, or into a design document or other place inside the repo).

I am of the opinion that in an ideal workflow the cover letter would be
part of the merge commit message. It may even be editorialized or
annotated by the maintainer performing the merge, but not necessarily so.

Currently I rarely pay attention to merges, because they are not exciting
(in a good way). I mostly know the texts that Junio puts into the merge
message[1] from the cooking email, and otherwise there is not much
information added there.

However looking at *what* Junio puts there, is "why is this worthwhile
to merge from the *projects* point of view?", whereas the cover letter
most of the time talks about "Why the *contributor* wants this merged".
Often these are subtly different, so it would be nice to have these
two competing views around.

[1] e.g. cf. da15b78e52 Merge branch 'jk/ui-color-always-to-auto'

quoted

As a separate follow on, one thing that does annoy me is that in subsequent
versions of the various patch series, folk tend to drop all explanation of
why the series is of any relevance, leaving just the 'changed since last
time' part. This means that new readers who try and pick up / review /
contribute to a series later on in its development are not told the purpose.
When the list is active it can, accidentally, do a disservice to the
potential contributors who may feel that only core contributors are able to
contribute.

I actually have the opposite opinion. I find it annoying to have to wade
through the same unchanged content for each round just to find the
little snippet of "here's what's changed".

Would you be happier if the "What changed?" goes first[2]?
Though I think whether to just reply to the previous version, put an
explicit link or copy the cover letter verbatim from last time is up
for discussion. I tent to think a link ought to be enough, because
those familiar with the topic would not follow it (so they have no
additional burden compared to direct copy), and new comers to
that topic may be ok with links .

[2] I tried following that style, e.g.
https://public-inbox.org/git/20170630205310.7380-1-sbeller@google.com/

I don't mind following a link to the previous iteration to read the
back-story if I wasn't involved (it's a good idea to do that anyway to
see what previous reviews have already discussed).

Such a back story would make an excellent merge message, too,
as it explains the big picture more accurately, often shows
alternatives considered etc.

Stefan