* Kees Cook <k...@kernel.org> [250213 14:34]: > > > On February 13, 2025 10:35:21 AM PST, "Liam R. Howlett" > <liam.howl...@oracle.com> wrote: > >* Kees Cook <k...@kernel.org> [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, jef...@chromium.org wrote: > >> > > From: Jeff Xu <jef...@chromium.org> > >> > > > >> > > 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.
Yes, rationales in the cover letter. I like the way the akpm's tree does things because it's the best of both worlds. There is also a separation of the cover letter with the actual commit message on the first patch. Having the full cover letter on patch 1 makes it difficult to understand *that* patch on its own during review. I've also gotten emails from Linus asking why in the ____ing ____ I did it this way when I said why in the cover letter.. to that note I like the patches to have _all_ the necessary details for that one patch, including the sometimes "this is changed in the very next patch" lines to spell out in-transit patches, or what ever else is needed from the cover letter/context. Taking this example, we have a 111 line cover letter and a patch that adds a new file with a single function, and two kconfig options. The justification and reason for the patch is in the middle of that huge block of text. That seems silly. That is to say: Cover letters have the rationale and over-arching reason. Patches have more than enough details to code inspect and know why this patch is necessary. Thanks, Liam
