Stefan Beller <sbeller@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html