> 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

Reply via email to