This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Stop updating ChangeLog?
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