Stefan Beller <> writes:

> In your work flow, how do you respect the cover letter?
> e.g. in 3787e3c16ced:
>     Merge branch 'ew/http-backend-batch-headers'
>     The http-backend (the server-side component of smart-http
>     transport) used to trickle the HTTP header one at a time.  Now
>     these write(2)s are batched.
>     * ew/http-backend-batch-headers:
>       http-backend: buffer headers before sending
> Is the text from the original author (and if so from which version
> of the cover letter) or is it your work?

The source of truth in the merge log message is the "What's cooking"
report.  I really prefer to write these in my own words, as that is
a good yardstick to measure how much/little I understand the topic.
If I cannot describe it concisely, in a way suitable as an entry in
the release notes, that means I am merging a topic I do not have a
good idea about, which is quite irresponsive.  Forcing me to write
these myself keeps me honest.

Of course, if a cover letter describes the topic well, it would help
me write the entry in the "What's cooking" report.

It is a bit tricky to aim for the automation, though.  The cover is
an overview of the proposed log messages and typically tells a story
"I do this, and then this, and finally that", plus a reroll-specific
commentary like "what changed since the last round".  On the other
hand, the entries in the release notes gives a description of what
happened from a third-party's point of view.  They are told in
different voice for different target audience.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to