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: Should we restore manually maintained ChangeLogs Date: Tue, 08 Mar 2016 17:50:29 +0200 Message-ID: <83pov5rmt6.fsf@gnu.org> 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> <56DE0F6A.6010207@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457452303 10077 80.91.229.3 (8 Mar 2016 15:51:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2016 15:51:43 +0000 (UTC) Cc: mthl@gnu.org, johnw@gnu.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 16:51:38 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 1adJv2-0003CG-7g for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 16:51:32 +0100 Original-Received: from localhost ([::1]:35455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJv1-0007gP-N6 for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 10:51:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJut-0007Z6-Sm for emacs-devel@gnu.org; Tue, 08 Mar 2016 10:51:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adJus-0004xd-J3 for emacs-devel@gnu.org; Tue, 08 Mar 2016 10:51:23 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJuo-0004vY-M5; Tue, 08 Mar 2016 10:51:18 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2696 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1adJun-0003NJ-8e; Tue, 08 Mar 2016 10:51:18 -0500 In-reply-to: <56DE0F6A.6010207@cs.ucla.edu> (message from Paul Eggert on Mon, 7 Mar 2016 15:31:54 -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:201154 Archived-At: > Cc: johnw@gnu.org, mthl@gnu.org, emacs-devel@gnu.org > From: Paul Eggert > Date: Mon, 7 Mar 2016 15:31:54 -0800 > > 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. With or without git-merge-changelog? If you have git-merge-changelog installed, what kind of screwups did you see with ChangeLogs? (I didn't see even one, in all the years I use Git.) > 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. The current approach completely breaks down when more than one branch is active. So there's no baby in that 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. Not sure what you mean here. What alternatives that don't "cater to all sides" would you suggest? The only one I see is to stop producing ChangeLog files for the releases. > ChangeLog mistakes can be easily fixed. > > That's true under both the old and the new regimes. No, it isn't. Definitely not with two branches. > 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. Don't know what hides behind "etc", but the rest are much smaller projects, which are all in maintenance mode, and have a very small number of active committers (of which you personally are a significant fraction ;-). They also don't use branches, at least not as much as we do. So I don't see how the experience of these projects is more relevant to us than that of GCC, GDB, Binutils, and glibc. > I could fairly easily change the master branch to do that. Please describe the details of your proposal. Also, please tell what do you suggest doing on the release branches. > 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". As I said, tossing ChangeLog files entirely would indeed solve the problems, but it's a sure path to further deterioration in the quality of log messages. It is easy to keep the quality in a project that has a small number of committers who are veteran GNU developers (Guile has 1 frequent committer on master, and 3 on stable). That's not our case. > 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. Any suggested approach should support not only the current emacs-25 branch, but also the future release branches, i.e. it should continue working when we cut the emacs-26 branch in the future. It should also be reliable, and not require manual labor for fixing mistakes in the log messages, beyond the fix itself. > 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. XEmacs is not that different from Grep or Sed. Sed, for example, saw just 30 commits during all of the last year. > 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. It's the other way around, actually: the current situation requires more labor from us to get it right, so our lack of resources should lead us to the opposite conclusion. > 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. Fixing its mistakes involves moving an entry to a different place, that's all. Easy done, and even if not done, it's not a disaster, as the information is there anyway.