Stefan Beller <sbel...@google.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html