On February 13, 2025 10:35:21 AM PST, "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx> wrote: >* Kees Cook <kees@xxxxxxxxxx> [250212 17:05]: >> On Wed, Feb 12, 2025 at 11:24:35AM +0000, Lorenzo Stoakes wrote: >> > On Wed, Feb 12, 2025 at 03:21:48AM +0000, jeffxu@xxxxxxxxxxxx wrote: >> > > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> >> > > >> > > The commit message in the first patch contains the full description of >> > > this series. >> > >> > Sorry to nit, but it'd be useful to reproduce in the cover letter too! But >> > this obviously isn't urgent, just be nice when we un-RFC. >> >> I advised Jeff against this because I've found it can sometimes cause >> "thread splitting" in that some people reply to the cover letter, and >> some people reply to the first patch, etc. I've tended to try to keep >> cover letters very general, with the bulk of the prose in the first >> patch. > >Interesting idea, but I think thread splitting is less of a concern than >diluting the meaning of a patch by including a lengthy change log with a >fraction of the text being about the code that follows. > >I think this is the reason for a cover letter in the first place; not >just version control. After all, we could tack the version information >into the first patch too and avoid it being in the final commit message. Okay, so to be clear: you'd prefer to put the rationales and other stuff in the cover, and put more specific details in the first patch? I've not liked this because cover letters aren't (except for akpm's trees) included anywhere in git, which makes archeology much harder. -Kees -- Kees Cook