Re: Stop updating ChangeLog?

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2018-02-06 13:57, Dennis Clarke wrote:
> 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

The curl ChangeLog seems to list all (or part?) of the commits since the 
last release.  So you can't really compare GNU ChangeLogs to curl 
ChangeLogs.  The curl ChangeLog is meant for user consumption, while the 
GNU ChangeLog as GDB does it is meant for developers.

When you get your hands on a fresh tarball of GDB, do you really read 
the ChangeLog?  What kind of meaningful information do you get from it?  
I don't think our ChangeLog contains anything that a user would care 
about.  When I use a program, I don't care about what function was 
renamed to what, what structure was removed, etc.

The NEWS file is very interesting to users though, I would see that as 
the "quality statement" for releases.  Except it doesn't tell what bugs 
were fixed.  When we do a .1 release (e.g. 8.0.1), our beloved release 
manager includes in the announcement a list of bugs that were fixed 
since the corresponding major release (e.g. 8.0).  But I don't think we 
do that between major releases (e.g. between 8.0.1 and 8.1).  Maybe it 
would be useful if we did?  It would certainly be easier for users to 
look a the list of fixed bugs than the ChangeLog.  The thing is that 
we'll still ask users to try with the latest release, because it's very 
possible that their bug has been fixed in a later version, but is not 
listed in the fixed bugs list.  It happens often that a bug we didn't 
even know existed disappears as part of some code rework.  So we still 
need confirmation that the bug exists in the latest release, or even 
better on master.

Simon