On Sun, Feb 26, 2023 at 11:42:25PM +0100, Diederik de Haas wrote: >... > The reason that I'm such a proponent of that is that 3 weeks or 3 months from > now, there's a reasonable chance that you (the author/committer) does no > longer remember the details of that commit. > In 3+ years that will be close to 0. > AFAIK actual mind reading does not exist, so someone else surely wouldn't > know. > > I've already encountered several cases where the commit was 10+ years old and > the commit msg what "Disable setting X" and looking at the diff, I can see > the > X was indeed disabled. But nothing more. > But now I want to enable setting X. But I have no context to know why that > would be a bad idea, or actually a good idea *now*, or what will break as a > consequence of my enabling X. All I can do is enable X and keep an eye out > for > bug reports. > > I think that's what you want to achieve with 'better' changelogs is something > similar. I think the git commits are a better place as it's easier to make > finer grained distinctions and it's more directly linked to the changes. >...
Where applicable: You can add comments in debian/rules. You can write long descriptions in debian/patches/*.patch That's even more directly linked to the changes. You can also write 5 line changelog entries. The "if" and "where" are likely far less related than you hope: People tend to be either terse or verbose, not terse in the package but verbose in git commits. And when trying to improve verbosity, this shouldn't be only in the git metadata outside the package. > Cheers, > Diederik cu Adrian
