Simon Richter <s...@debian.org> writes: > A better approach would not treat Debian metadata as git data. Even the > most vocal advocate of switching everything to Salsa writes in his MR > that the changelog should not be touched in a commit, because it creates > conflicts, and instead a manual step will need to be performed later.
This is not a Debian-specific problem and has nothing to do with any special properties of our workflows or differences between packaging and other software maintenance tasks. It's a common issue faced by everyone who has ever maintained a software package in Git and wanted to publish a change log. There are oodles of tools and workflows to handle this problem, ranging from writing the change log based on the Git commits when you're making the release to accumulating fragments of release notes in separate files and using a tool to merge them. dch's approach of using the Git commit messages is one of the standard solutions, one that will be familiar to many people who have faced this same problem in other contexts. The hard part with these sorts of problems is agreeing on the tool and workflow to use to solve it, something Debian struggles with more than most software projects because we lack a decision-making body that can say things like "we're going to use scriv" and make it stick. But that isn't because packaging is a special problem unsuited to Git. Git has a rich ecosystem with many effective solutions to problems of this sort. It's because we've chosen a governance model that intentionally makes central decision-making and therefore consistency and coordination difficult, in exchange for other perceived benefits. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
