> ChangeLog entries are trivial and quick to write, and save so much This whole proposal is because they are not at all trivial or quick to write for the sorts of changes that are common in projects such as glibc or GCC, which are very different from the small local changes illustrated in the example ChangeLog entries in the GNU Coding Standards.
Then we should look into ways to make them quicker for these cases instead of throwing out the baby with the bath water. I showed an example on how they are easy and quick to write for changes that affect many similar files, still using the current way of writing them. If you can show how they are complicated maybe this dicussion can be turned into something a bit more interesting? They also serve unnecessarily to isolate GNU from the broader free software community and discourage people working on a wide range of free software from contributing to GNU, by adding an additional GNU-specific format people need to learn that isn't useful elsewhere, when many extremely active free software projects such as the Linux kernel have evidently found fully functional ways of understanding code history and achieving the purposes of ChangeLogs without the ChangeLog format - ways which are useful extremely broadly across free software rather than being GNU-specific as ChangeLogs are. If ChangeLogs isolate the GNU project some how, I don't know nor is it very relevant, it just moves the discussion from if they are useful or not to hypothetical speculation as to what people might or might not think about topics that can't be quantified. Linux is also a poor example to highlight how ChangeLog might hypothetically impede a project seeing that the maintainer is activley hostile towards our goals, and that Linux includes non-free software and why we have Linux-Libre