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:45:49 +0200 Message-ID: <83si01rn0y.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> <1ceba0e3-b8a7-393d-ce41-213aee11b7f8@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457451984 4367 80.91.229.3 (8 Mar 2016 15:46:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2016 15:46:24 +0000 (UTC) Cc: mthl@gnu.org, eggert@cs.ucla.edu, johnw@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 16:46:13 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 1adJpj-0007HZ-RC for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 16:46:04 +0100 Original-Received: from localhost ([::1]:35433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJpe-0004A9-77 for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 10:45:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJpX-00049f-Ui for emacs-devel@gnu.org; Tue, 08 Mar 2016 10:45:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adJpR-0003EY-UE for emacs-devel@gnu.org; Tue, 08 Mar 2016 10:45:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJpN-0003DF-16; Tue, 08 Mar 2016 10:45:41 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2686 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1adJpM-0002pm-0h; Tue, 08 Mar 2016 10:45:40 -0500 In-reply-to: <1ceba0e3-b8a7-393d-ce41-213aee11b7f8@yandex.ru> (message from Dmitry Gutov on Mon, 7 Mar 2016 23:42:33 +0200) 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:201151 Archived-At: > Cc: mthl@gnu.org, johnw@gnu.org, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 7 Mar 2016 23:42:33 +0200 > > 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! > > Only when merging between branches. It doesn't work very well even on a single branch. With two branches, it completely breaks down. We do want to work on multiple branches, don't we? We discussed how to make more frequent releases, and perhaps have 3 branches for even more flexible development and release schedule. All of that would be impossible because of this tiny but annoying PITA. Do we really want to continue wasting energy on fixing something that wasn't such a big problem to begin with? > Other than that, only a select group of people needs to bother: those who make mistakes, and those who feel a general need to clean up. See, that's the crux of the issue: do we or don't we care about the need to clean up our ChangeLogs? If we don't, then why bother maintaining them? You (and some others) say the format and the content in the log messages are important, and I agree. But if we do care about them, how can we NOT clean them up? Having them in their current state means they cannot be trusted, which is worse than not having them at all. > As a relatively careful committer, I've only had to correct the entries a few times, and I've been enjoying the lack of collisions quite a bit. Yes, a few of us don't need any corrections. But enough of us do, and that's where the problem lies. It is that problem that we need to fix. Leaving it unfixed makes your accurate work unreliable as well. > But ChangeLog mistakes can be easily fixed. > > In the current approach, as well. Only on a single branch, and even there this is not done enough. We all relied on Glenn to do that behind the scenes. Now Glenn gave up in despair, so things will degrade from now on. > 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. > > I think we should wait and see until the work really transitions back to master. The motivation must rise. The release branch will remain active for quite some time: we have just started a new major version. And if we want more frequent releases, we should strive to have an active release branch at all times. So I don't think we can wait; waiting will not solve anything, it will just make the current problems bigger and harder to solve. > 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. > > Has the current experiment really sucked too much energy from anyone, aside from the implementors? Why do you think Glenn gave up? > 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. > > For all we know, they might be thriving despite this practice. Nothing wrong with that. > 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 either. I've still had collisions, and even when git-merge-changelog resolved them, it often put my entry in the middle of the file, whereas I usually needed it to be at the top. Leading to extra manual labor. That extra manual labor is very small, and it's still a rare case to have that. A small price to pay for a clean and reliable solution. > 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. > > It was longer for me. But either way, it's more hassle for a random contributor than the current system. The current system is much more hassle for non-random contributors, so much so that we risk losing them, something we cannot afford. > If it can be fixed, Someone should. Let that Someone step forward, then, and speak up. We have been waiting for that for the past year, so I'm not holding my breath now.