Re: Stop updating ChangeLog?

[Dennis Clarke <dclarke@blastwave.org>]

On 06/02/18 02:33 AM, Joel Brobecker wrote:
>>> Joseph,
>>> The format of ChangLog entry is out of the scope of this discussion.
>>> IMO, each project is free to choose whether to write changelog entry
>>> or not (either in commit log or ChangeLog file).  Some GNU projects
>>
>> I don't believe they are so free (yet).  The current (and problematic) GCS
>> requirement, that I've been trying to get changed, is for ChangeLog files
>> in releases, using a particular format (which I don't think is a good
>> format since it forces description at the level of changed to individual
>> files and named entities therein, which closely duplicates the information
>> in the diffs themselves) - the projects may choose whether that's a
>> checked-in file or generated automatically.
> 
> Joseph is absolutely right, in that, as a GNU project, GDB is
> expected to follow the GNU Coding Standards. So we all need to go
> and contribute to the dicussion on the bug-standards list.
> Let's get rid of the ChangeLog format!
> 

SUMMARY : ChangeLog is part of the quality statement for a given
           production release


I tend to look at this a bit differently. I see the releases from any
given project as being a "production" grade release or perhaps even as
"stable" and then everything else is "beta" and even work in progress.
Those sort of things may be seen with "git diff foo HEAD" for those
things where git has crawled in and become the cvs or svn tool du jour.
When a project, GNU or Apache or otherwise, makes a version release and
they use that term "stable" or perhaps "production" then there is a
statement of some level of quality implied. I see work happening all the
time inside the Curl/libCurl project and Daniel Stenberg is quite active
and reasonable about checking with people on the state of bugs before a
move to a "release" or a "stable" version dropped on the world. There is
always a Changelog ( https://curl.haxx.se/changes.html ) wherein people
may get a sense that yes indeed bugs were addressed.

The purpose of the ChangeLog file would be to make a firm statement that
a given version is in fact considered "stable" and fit for production
grade usage in any environment. If a user appears with their hands
raised saying there is a bug in gdb 8.0.1 then the first response would
be "the stable release is 8.1 and you need to look there" as well as
maybe, perhaps, the ChangeLog that shows the bug was already addressed.
The ChangeLog is a statement of a given expectation for "stable" quality
or perhaps even a "release" to be used by anyone anywhere. There is only
one place to look for a given project release and that would be ye old
site ftp://ftp.gnu.org/pub ( or perhaps ftp://prep.ai.mit.edu/pub/ for
those of us old enough ) whereupon we see a "release" for GNU patch
today as version 2.7.6.  The first actual release since 2015 which will
have years of work applied to it. However this code tarball is deemed to
be "stable" and thus considered "production" grade. There are a strange
multitude of compression types for tarballs on the ftp server where we
may get :


admsys@sedna$ ls -lap
total 2792
drwxrwxr-x.  8 admsys admsys   4096 Feb  3 18:46 ./
drwxr-xr-x. 54 admsys admsys  16384 Feb  6 18:36 ../
-rw-rw-r--.  1 admsys admsys      6 Feb  3 18:46 .tarball-version
-rw-rw-r--.  1 admsys admsys      6 Feb  3 13:42 .version
-rw-rw-r--.  1 admsys admsys    335 Sep  4 11:34 AUTHORS
-rw-rw-r--.  1 admsys admsys  35147 Sep  4 11:34 COPYING
-rw-rw-r--.  1 admsys admsys  54913 Feb  3 18:46 ChangeLog
-rw-rw-r--.  1 admsys admsys 142258 Sep  4 11:34 ChangeLog-2011
-rw-rw-r--.  1 admsys admsys   4574 Feb  3 13:42 GNUmakefile
-rw-rw-r--.  1 admsys admsys  15756 Feb  3 12:41 INSTALL
-rw-rw-r--.  1 admsys admsys   1630 Feb  3 13:40 Makefile.am
-rw-rw-r--.  1 admsys admsys  62989 Feb  3 13:41 Makefile.in
-rw-rw-r--.  1 admsys admsys  15988 Feb  3 18:43 NEWS
-rw-rw-r--.  1 admsys admsys   2784 Feb  3 18:43 README
-rw-rw-r--.  1 admsys admsys    261 Sep  4 11:34 TODO
-rw-rw-r--.  1 admsys admsys  67870 Feb  3 13:33 aclocal.m4
-rwxrwxr-x.  1 admsys admsys  31523 Feb  3 12:41 bootstrap
drwxrwxr-x.  2 admsys admsys   4096 Feb  3 18:46 build-aux/
-rw-rw-r--.  1 admsys admsys   1320 Sep  4 11:34 cfg.mk
-rw-rw-r--.  1 admsys admsys  65938 Feb  3 13:33 config.hin
-rwxrwxr-x.  1 admsys admsys 714015 Feb  3 13:41 configure
-rw-rw-r--.  1 admsys admsys   5756 Feb  3 12:41 configure.ac
drwxrwxr-x.  2 admsys admsys   8192 Feb  3 18:46 lib/
drwxrwxr-x.  2 admsys admsys   8192 Feb  3 18:45 m4/
-rw-rw-r--.  1 admsys admsys  63844 Feb  3 12:41 maint.mk
-rw-rw-r--.  1 admsys admsys  34708 Feb  3 12:41 patch.man
drwxrwxr-x.  3 admsys admsys     37 Sep  4 11:33 pc/
drwxrwxr-x.  2 admsys admsys    265 Feb  3 18:46 src/
drwxrwxr-x.  2 admsys admsys   4096 Feb  3 18:46 tests/


The ChangeLog that is included in a given "release" would be one of the
first things to look at. Here. Not a git diff report or even some web
site somewhere.  Why?  Because projects fold up and die or they get
absorbed into other projects. Perhaps gdb will fold into a single large
binutils project?  I can't predict the future but I can say with a high
degree of certainty that code projects evolve, change, and die. People
move around ( Jim Meyering for example ) and often leave projects behind
entirely. Remove the ChangeLog from the "production" grade "release" and
I would ask what do you replace that information with?

Dennis Clarke