From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51100 invoked by alias); 6 Feb 2018 19:55:32 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 51090 invoked by uid 89); 6 Feb 2018 19:55:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,BELOVED_BODY,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=beloved, UD:se, jour, UD:mit.edu X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 19:55:23 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w16JtHch031488 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 6 Feb 2018 14:55:21 -0500 Received: by simark.ca (Postfix, from userid 112) id 33B9B1E757; Tue, 6 Feb 2018 14:55:17 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 887811E4F4; Tue, 6 Feb 2018 14:55:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 06 Feb 2018 19:55:00 -0000 From: Simon Marchi To: Dennis Clarke Cc: gdb@sourceware.org Subject: Re: Stop updating ChangeLog? In-Reply-To: References: <20180206073354.juuhsw4q7tzi74w2@adacore.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 6 Feb 2018 19:55:17 +0000 X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00048.txt.bz2 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