From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1121 invoked by alias); 6 Feb 2018 18:57:37 -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 1109 invoked by uid 89); 6 Feb 2018 18:57:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=expectation, UD:se, jour, UD:mit.edu X-HELO: jax4mhob07.myregisteredsite.com Received: from jax4mhob07.myregisteredsite.com (HELO jax4mhob07.myregisteredsite.com) (64.69.218.87) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 18:57:33 +0000 Received: from mailpod.hostingplatform.com ([10.30.77.35]) by jax4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id w16IvTkD024594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 Feb 2018 13:57:29 -0500 Received: (qmail 14259 invoked by uid 0); 6 Feb 2018 18:57:29 -0000 X-TCPREMOTEIP: 99.253.103.29 X-Authenticated-UID: dclarke@blastwave.org Received: from unknown (HELO sedna.genunix.com) (dclarke@blastwave.org@99.253.103.29) by 0 with ESMTPA; 6 Feb 2018 18:57:28 -0000 Subject: Re: Stop updating ChangeLog? To: gdb@sourceware.org References: <20180206073354.juuhsw4q7tzi74w2@adacore.com> From: Dennis Clarke Message-ID: Date: Tue, 06 Feb 2018 18:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180206073354.juuhsw4q7tzi74w2@adacore.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00047.txt.bz2 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