From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Should we restore manually maintained ChangeLogs Date: Mon, 7 Mar 2016 15:31:54 -0800 Organization: UCLA Computer Science Department Message-ID: <56DE0F6A.6010207@cs.ucla.edu> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <87vb4zb0i4.fsf@gnu.org> <837fheuu6a.fsf@gnu.org> <83twkiteb3.fsf@gnu.org> <83lh5utbxb.fsf@gnu.org> <56DDD02A.20809@cs.ucla.edu> <83fuw2t2ue.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1457393554 15020 80.91.229.3 (7 Mar 2016 23:32:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2016 23:32:34 +0000 (UTC) Cc: mthl@gnu.org, johnw@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 00:32:25 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 1ad4dQ-0008Vq-WF for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 00:32:21 +0100 Original-Received: from localhost ([::1]:59182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad4dQ-0000t2-Bt for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2016 18:32:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad4dD-0000sv-Jg for emacs-devel@gnu.org; Mon, 07 Mar 2016 18:32:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad4dB-0000rz-8G for emacs-devel@gnu.org; Mon, 07 Mar 2016 18:32:07 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad4d2-0000pp-Vs; Mon, 07 Mar 2016 18:31:57 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1A82516057C; Mon, 7 Mar 2016 15:31:56 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id T1AnIG2hFtXG; Mon, 7 Mar 2016 15:31:55 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 497A7160E85; Mon, 7 Mar 2016 15:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p4p2BEiDboxb; Mon, 7 Mar 2016 15:31:55 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2E56D16057C; Mon, 7 Mar 2016 15:31:55 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <83fuw2t2ue.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:201098 Archived-At: On 03/07/2016 01:06 PM, Eli Zaretskii wrote: >> Maintaining ChangeLog files by hand with each commit makes it harder >> to merge changes due to the inevitable collisions with ChangeLog >> files. > Incorrect! And the current situation creates _more_ collisions, not > less! My own experience is otherwise. For the kinds of development I do, I rarely see ChangeLog screwups now, whereas I used to see them routinely. I far prefer the current approach. Of course our approach can be improved (in particular merging from emacs-25 to master doesn't work well now), but let's not throw out the baby with the bathwater. > We don't have to be better than the other prominent GNU projects. I'd be happy if we were merely as good as the other prominent GNU projects that generate ChangeLog entries automatically. As things stand, due to our attempt to cater to all sides of this disagreement, we have an approach that satisfies nobody. > ChangeLog mistakes can be easily fixed. That's true under both the old and the new regimes. > Let other projects invent those schemes and test-drive them. Enough > with these experiments! I'd rather just do what coreutils, grep, tar, etc. use. It's just as simple for ordinary committers and it would not involve duplication in patches or experimentation with maintenance procedures. I could fairly easily change the master branch to do that. Even simpler would be to do what Guile does: it dispenses with ChangeLogs entirely. With Guile if you want something like a ChangeLog you run "git log". If neither of the above two approaches suffice, we can always fall back on my previous email's proposal. It's not that experiemental, as it says to use the new produre on master and the old procedure on emacs-25. The new procedure works well enough within a single master branch. Of all the above, though, Guile's approach is the simplest and is probably the best for us overall. > these procedures work, and all those projects are alive and kicking, > and actually make more frequent releases than we do. XEmacs is not really alive and kicking. Projects like GCC and glibc have more resources than we do, and can afford to insist on more-expert contributions that involve harder-to-generate patch formats. We do not have that luxury. > >> I often ran into problems. Yes, git-merge-changelog should reduce the >> number of merge conflicts, but it doesn't eliminate them > Oh, yes, it does. Not in my experience, or in Dmitry's. It's a fine program, but it sometimes makes mistakes and they can be a pain to fix.