On Wed, May 28, 2025 at 04:39:01PM +0200, Danilo Krummrich wrote: > On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote: > > On Wed, May 28, 2025 at 8:45 AM Simona Vetter <simona.vet...@ffwll.ch> > > wrote: > > > I do occasionally find it useful as a record of different approaches > > > considered, which sometimes people fail to adequately cover in their > > > commit messages. Also useful indicator of how cursed a patch is :-) > > > > > > But as long as anything relevant does end up in the commit message and > > > people don't just delete stuff I don't care how it's done at all. It's > > > just that the cost of deleting something that should have been there can > > > be really nasty sometimes, and storage is cheap. > > > > I like them for the same reasons. Also, even with links, sometimes > > there are forks of the conversation that get missed that a changelog > > provides some insight into. I find it useful in my own development as > > I can note what I've changed in a patch and can retain that in the > > commit rather than as something I need to track separately and then > > add to the patches when I send them out. > > Personally, I don't think it's super useful in the commit message, it still > remains in the patches sent to the mailing list though. And since we put lore > links everywhere, it's easily accessible, *including* the context of why a > change was made from one version to another, i.e. the full conversation. > > However, if we really want that, we should make it an offical thing, since > currently the kernel's process documentation [1] clearly states otherwise: > > "Please put this information after the '---' line which separates the > changelog > from the rest of the patch. The version information is not part of the > changelog > which gets committed to the git tree. It is additional information for the > reviewers. If it's placed above the commit tags, it needs manual interaction > to > remove it." > > Alternatively, it can go into the cover letter.
One additional note: This is not me trying to be super bureaucratic; instead I think being consistent in the process across the whole kernel results in a better experience for (new) contributors. > [1] https://docs.kernel.org/process/submitting-patches.html#commentary
