From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102753 invoked by alias); 2 Feb 2018 16:27:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 102741 invoked by uid 89); 2 Feb 2018 16:27:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=filling, price, usefulness, pay 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; Fri, 02 Feb 2018 16:27:54 +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 w12GRmpD000818 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 2 Feb 2018 11:27:52 -0500 Received: by simark.ca (Postfix, from userid 112) id AFD671E75F; Fri, 2 Feb 2018 11:19:19 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 376F31E48F; Fri, 2 Feb 2018 11:19:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 02 Feb 2018 16:27:00 -0000 From: Simon Marchi To: Joel Brobecker Cc: Eli Zaretskii , Yao Qi , simon.marchi@ericsson.com, gdb-patches@sourceware.org Subject: Re: [ANNOUNCEMENT] GDB 8.1 release branch created! In-Reply-To: <20180202155308.vx7hkemrjfmb27mn@adacore.com> References: <83fu6sln4o.fsf@gnu.org> <3d75778f-5c91-5680-b9fa-c2f2c902ff67@ericsson.com> <838tcklaev.fsf@gnu.org> <83607njlsh.fsf@gnu.org> <86wozwbv68.fsf@gmail.com> <83shakeku7.fsf@gnu.org> <83mv0sehrq.fsf@gnu.org> <837erveqnz.fsf@gnu.org> <20180202155308.vx7hkemrjfmb27mn@adacore.com> Message-ID: <0d3105d4550cd3a68c9a3237bd556c08@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 2 Feb 2018 16:27:48 +0000 X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00036.txt.bz2 On 2018-02-02 10:53, Joel Brobecker wrote: > Well, if it were me, I would stop using ChangeLog files with > immediate effect. > > The purpose of ChangeLog files, as I understand it, is to describe > the "what changed", and is aimed at people who download a given > release and want to know what changed (because they do not have > access to the version control information). > > While the above might have been essential 20 or 25 years ago, > it is trivial for anyone today to have access to the change > history of our program. Two options: > - git clone our public repository; or... > - ... if they don't want to use git, they can use the gitweb > interface. > > I think that this is an acceptable way for us to provide the log > of changes that were made. > > Currently, the situation is that we all pay a price in term of time > wasted populating those files, and when we add the time collectively > spent on those, I cannot imagine the few people's convenience would > be worth that much effort. > > I vote for we stop using those ChangeLog files right now. We can > still have them as part of the ChangeLog if people want -- although, > I am also open to considering the pros and cons of keeping it, > but I think they might not be worth the investiment either. I agree about the time consumed producing ChangeLog entries. I have to admit that it sometimes discourages me to do structural changes that would affect a lot files/functions. I also feel like I'm filling some administrative paperwork, which is not my favorite way of spending my time. Maintaining an internal port of GDB, one use I have for the ChangeLog is to find what commit removed a given function. Let's say I rebase our code and find out a function we use was removed, grepping for that function would find the ChangeLog entry, leading me to the commit, which helps in fixing the code. However, I recently discovered "git blame --reverse", which allows to ask git about which commit removed a particular line. So the ChangeLog is not really required for that use case. Since with git the whole history is available offline, I think the usefulness of this kind of ChangeLogs is not as big as it used to be. To be fair I'll also state a pro I see for the ChangeLog. When I write the ChangeLog entry, it makes me look at my change a last time in details and sometimes find some additional issues I might not have found otherwise. It might be worth starting a new thread to get the attention of everybody to discuss this issue. Simon