From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is it time to drop ChangeLogs? Date: Wed, 09 Mar 2016 18:41:27 +0200 Message-ID: <8337rzpps8.fsf@gnu.org> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <64a52598-ad53-498c-993c-67d7827dbdfc@default> <838u1uuuau.fsf@gnu.org> <878u1um2xl.fsf@thinkpad.rath.org> <87fuw090k7.fsf@wanadoo.es> <83y49spuxt.fsf@gnu.org> <87pov4achc.fsf@acer.localhost.com> <83r3fkpb3u.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457541720 29940 80.91.229.3 (9 Mar 2016 16:42:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2016 16:42:00 +0000 (UTC) Cc: ofv@wanadoo.es, i.lohmar@gmail.com, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 09 17:41:53 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1adhB5-0004VL-3f for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 17:41:39 +0100 Original-Received: from localhost ([::1]:42502 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adhB4-0006sW-MC for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 11:41:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adhAn-0006pH-Pl for emacs-devel@gnu.org; Wed, 09 Mar 2016 11:41:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adhAm-0007lO-SR for emacs-devel@gnu.org; Wed, 09 Mar 2016 11:41:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adhAi-0007hs-GF; Wed, 09 Mar 2016 11:41:16 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3883 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1adhAh-0006zg-LJ; Wed, 09 Mar 2016 11:41:16 -0500 In-reply-to: (message from John Wiegley on Tue, 08 Mar 2016 22:41:49 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201254 Archived-At: > From: John Wiegley > Date: Tue, 08 Mar 2016 22:41:49 -0800 > Cc: ofv@wanadoo.es, Ingo Lohmar , emacs-devel@gnu.org > > > Find a better and more reliable way of dealing with the problems described > > here, and I'll be the first to agree not to reintroduce ChangeLogs. > > As far as I understand so far, we have only a few needs. If I've understood > incorrectly, please let me know, as this thread has wandered in a few places. > > 1. We need a way to ensure quality commit messages from contributors. > 2. We'd like to be able to correct commit messages after the fact. > 3. We need a convenient way to both create and access this information. > 4. We want to publish the history of these commit messages in the tarball. > > The ChangeLog file and its format are one implementation of these needs that > has worked over the years. Are you saying that if we move to something else, > and it fulfills these criteria, you'd be just as happy with it? Yes. However, putting on my system engineer hat, let me make sure the list of requirements covers all the aspects: 5. The "history of commit messages" produced in 4 above should resemble a ChangeLog file (ideally, it should use the same format). 6. The solution should allow manual generation of the "history" file mentioned in 4, on demand, in reasonably short time, even if the repo clone does not include a built Emacs. (It is okay to use the installed Emacs binary, if necessary.) 7. The solution should support Git workflows we allow: merging between branches, rebasing local changes on upstream, cherry-picking from another branch, reverting a commit, tagging a commit, and amending an unpushed commit. "Support" here means that the solution should not impose limitations on these workflows, and the steps for updating whatever databases the solution will use should not require additional manual work as result of using these workflows. (I'm not saying these additions are something non-obvious, I just want to make sure we have everything covered.)