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: Mon, 07 Mar 2016 23:06:33 +0200 Message-ID: <83fuw2t2ue.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457384818 6976 80.91.229.3 (7 Mar 2016 21:06:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2016 21:06:58 +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 Mon Mar 07 22:06:40 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 1ad2MR-00067D-3w for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2016 22:06:39 +0100 Original-Received: from localhost ([::1]:58570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad2MQ-0000UW-Ji for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2016 16:06:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48300) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad2MM-0000UD-9B for emacs-devel@gnu.org; Mon, 07 Mar 2016 16:06:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad2ML-0005yG-7c for emacs-devel@gnu.org; Mon, 07 Mar 2016 16:06:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad2MG-0005x6-14; Mon, 07 Mar 2016 16:06:28 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1731 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ad2ME-0002eT-Tv; Mon, 07 Mar 2016 16:06:27 -0500 In-reply-to: <56DDD02A.20809@cs.ucla.edu> (message from Paul Eggert on Mon, 7 Mar 2016 11:02:02 -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:201074 Archived-At: > Cc: mthl@gnu.org, emacs-devel@gnu.org > From: Paul Eggert > Date: Mon, 7 Mar 2016 11:02:02 -0800 > > 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! > Although other projects that continue to use this older style (e.g., > glibc) work around the problem by requiring contributors to deal > with the hassles, this is one more barrier to contributions and > there are better alternatives. We don't have to be better than the other prominent GNU projects. > > mistakes in the log messages are not corrected > > This is a problem regardless of whether ChangeLog files are updated by > each commit. Under either approach, contributors often make mistakes in > their ChangeLog entries, and don't bother to fix them because (let's > face it) ChangeLog entries are low priority. But ChangeLog mistakes can be easily fixed. > > there's an unsolved problem of merging from the release branch to master. > > We can solve that problem. (It hasn't been high priority to fix.) We don't know how, and we don't have anyone who is motivated enough to do that. And even if and when we do have some solution, it is likely to be inconvenient and unreliable. > Here's one simple way to fix it: run the automated ChangeLog generator > only on the master branch, as was originally intended, and use manual > updates to ChangeLog files in other branches. (The hassle of manually > maintaining ChangeLog files on emacs-25 will serve to discourage further > changes to the emacs-25 branch, which is arguably a good thing. :-) We > can come up with a better approach later. Let other projects invent those schemes and test-drive them. Enough with these experiments! They draw the last drops of energy from us, and they avert the few last veteran contributors we have left. > > Other projects maintain ChangeLog files in the repository: GCC, > > Binutils, GDB, glibc, Texinfo, XEmacs, to name just those that I know > > about. > > These are all longstanding projects that haven't changed their > procedures for ages. That's not a bad thing in itself. The point is, these procedures work, and all those projects are alive and kicking, and actually make more frequent releases than we do. > > We have maintained ChangeLog files in the repo for years, and I don't > > remember this ever being a problem, provided that a proper merge tool > > (git-merge-changelog for Git) is installed. > > 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. > requiring git-merge-changelog means that many contributors would > have to worry about installing and configuring git-merge-changelog, > which would be more of a hassle for recruiting contributors. It's a 5-sec configuration, let's not make a mountain out of a molehill. > I should mention that git-merge-changelog effectively has no maintainer > now; if we run into a problem with it, we'll have to maintain it ourselves. There's no need for a maintainer, as there are no problems. I'm using that program all the time.