GNU bug report logs - #19113
Generate a ChangeLog file from commit logs

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Wed, 19 Nov 2014 23:59:02 UTC

Severity: wishlist

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19113 in the body.
You can then email your comments to 19113 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Wed, 19 Nov 2014 23:59:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Eggert <eggert <at> cs.ucla.edu>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 19 Nov 2014 23:59:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Subject: Generate a ChangeLog file from commit logs
Date: Wed, 19 Nov 2014 15:57:41 -0800
[Message part 1 (text/plain, inline)]
Tags: patch

Attached are two patches to change the Emacs repository so that the distributed 
ChangeLog file is generated automatically from commit logs, instead of being 
maintained manually.  The first patch renames every ChangeLog file to 
ChangeLog.1 (or whatever) to get it out of the way -- that is, all existing 
ChangeLog files are retained in the repository as before.  The second patch 
arranges for the new ChangeLog file to be generated automatically from future 
commit messages.  The idea is that developers should continue to write commit 
messages in ChangeLog style, so the automatic generation is straightforward, but 
they needn't record their commit messages in ChangeLog files.  This approach was 
developed by Jim Meyering is used by several other GNU packages.

This is a first cut, and no doubt could be improved for Emacs, but I thought I'd 
start the ball rolling by publishing something that works for me.

These patches are relative to emacs-24 commit cd2e816 
<2014-11-19T19:29:40Z!eggert <at> cs.ucla.edu>.

PS.  The first patch would be about 12 MB, so I'm attaching an abbreviated 
summary of it instead of the actual patch; it can be reproduced using the 
summary's recipe.
[0001-Rename-old-ChangeLog-files-to-prepare-for-gitlog-to-.patch (text/x-diff, attachment)]
[0002-Generate-a-ChangeLog-file-from-commit-logs.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Thu, 20 Nov 2014 15:52:02 GMT) Full text and rfc822 format available.

Message #8 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 20 Nov 2014 17:51:29 +0200
> Date: Wed, 19 Nov 2014 15:57:41 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> Attached are two patches to change the Emacs repository so that the distributed 
> ChangeLog file is generated automatically from commit logs, instead of being 
> maintained manually.  The first patch renames every ChangeLog file to 
> ChangeLog.1 (or whatever) to get it out of the way -- that is, all existing 
> ChangeLog files are retained in the repository as before.  The second patch 
> arranges for the new ChangeLog file to be generated automatically from future 
> commit messages.  The idea is that developers should continue to write commit 
> messages in ChangeLog style, so the automatic generation is straightforward, but 
> they needn't record their commit messages in ChangeLog files.  This approach was 
> developed by Jim Meyering is used by several other GNU packages.
> 
> This is a first cut, and no doubt could be improved for Emacs, but I thought I'd 
> start the ball rolling by publishing something that works for me.

What's the plan for preventing the generated ChangeLog file from
becoming too large?  Currently, we roll them over to keep the file
below 1MB.

I looked at Coreutils.  They started using a generated file in 2008.
Now, after 6 years, the ChangeLog is over 1MB in size.  Emacs's commit
rate is about 12 times higher than that of Coreutils, so we will hit
that mark in about 6 months.  What then?  gitlog-to-changelog doesn't
have provisions for rolling over, and cannot be told to stop at a
given date.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Thu, 20 Nov 2014 17:26:02 GMT) Full text and rfc822 format available.

Message #11 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 19113 <at> debbugs.gnu.org
Subject: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 20 Nov 2014 17:25:05 +0000
gitlog-to-changelog takes the same options as `git log`
so it should be easy enough to generate logs for the
last n versions, or the last x versions in the last N years etc.
and discard anything older (which can/should be looked up in git if required).

I'm considering removing any of these old logs
from coreutils that are already in git logs:

$ find -name "ChangeLog*" | xargs du -hsc | sort -h
8.0K	./build-aux/ChangeLog-2007
8.0K	./po/ChangeLog-2007
16K	./ChangeLog-2008
64K	./old/sh-utils/ChangeLog.0
72K	./doc/ChangeLog-2007
152K	./ChangeLog-2006
156K	./ChangeLog-2007
164K	./old/sh-utils/ChangeLog
172K	./m4/ChangeLog-2007
220K	./old/fileutils/ChangeLog-1997
288K	./old/fileutils/ChangeLog
304K	./old/textutils/ChangeLog
312K	./lib/ChangeLog-2007
440K	./ChangeLog-2005
1.1M	./ChangeLog
3.4M	total

Pádraig.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Thu, 20 Nov 2014 17:45:04 GMT) Full text and rfc822 format available.

Message #14 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 20 Nov 2014 09:43:59 -0800
[Message part 1 (text/plain, inline)]
On 11/20/2014 07:51 AM, Eli Zaretskii wrote:
> What's the plan for preventing the generated ChangeLog file from
> becoming too large?
I added an --until option to gitlog-to-changelog so that we can generate 
a set of ChangeLogs rather than a single ChangeLog.  We can uses this 
once we want to generate multiple ChangeLogs.  I'll CC: this email to 
bug-gnulib since the source belongs to gnulib.  Patch attached.

[0001-gitlog-to-changelog-add-until.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Thu, 20 Nov 2014 17:45:04 GMT) Full text and rfc822 format available.

Message #17 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 20 Nov 2014 09:44:57 -0800
On 11/20/2014 07:51 AM, Eli Zaretskii wrote:
> Currently, we roll them over to keep the file below 1MB.

A 1 MB limit is too low nowadays.  Other GNU Emacs source files are as 
large as 6.8 MB and it's not a problem.  I suggest raising the size 
limit to 32 MB.   The issue of size is independent of the mechanism used 
to enforce it, of course.

Here's a more-radical suggestion: combine the existing ChangeLogs (there 
is about 24 MB worth) into a single ChangeLog.1 file at the top level.  
That would be under the 32 MB limit.  Or, if we prefer a smaller limit, 
16 MB say, we can create ChangeLog.1 and ChangeLog.2.  This suggestion 
is independent of the other suggestions.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Thu, 20 Nov 2014 18:02:01 GMT) Full text and rfc822 format available.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Achim Gratz <Stromeko <at> nexgo.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 20 Nov 2014 19:00:43 +0100
Eli Zaretskii writes:
> What's the plan for preventing the generated ChangeLog file from
> becoming too large?  Currently, we roll them over to keep the file
> below 1MB.

I haven't yet looked at what Emacs has implemented now… but you may want
to take a look at Org.  The ChangeLog there is generated for only the
segment of commits between releases to Emacs.  If we come up with a
reliable method to (auto-)mark the latest commit that has been picked up
for the ChangeLog, then it becomes trivial to a) do the rollover, either
manually or automatically; and b) edit entries in the ChangeLog for
style or substance that have fallen behind that barrier since the
auto-generation from commit messages will not touch them.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Wed, 26 Nov 2014 05:39:02 GMT) Full text and rfc822 format available.

Message #23 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Tue, 25 Nov 2014 21:38:28 -0800
[Message part 1 (text/plain, inline)]
Paul Eggert wrote:
> combine the existing ChangeLogs (there is
> about 24 MB worth) into a single ChangeLog.1 file at the top level.

I implemented this, along with some other fixes (notably, getting a proper 
copyright notice into the generated ChangeLog file), and am attaching the 
corresponding patches.  I would like to install this into the emacs-24 branch 
and then merge that into the master.

There are three patches.  Patches 1 and 3 are so large that I'm just attaching 
summaries here.  (Patch 1 is essentially the same as before.)  You can get the 
full patches temporarily from here:

http://cs.ucla.edu/~eggert/emacs/
[0001-Rename-old-ChangeLog-files-to-prepare-for-gitlog-to-.patch (text/x-diff, attachment)]
[0002-Generate-a-ChangeLog-file-from-commit-logs.patch (text/x-diff, attachment)]
[0003-Combine-all-historical-ChangeLogs-into-ChangeLog.1.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Wed, 26 Nov 2014 06:22:02 GMT) Full text and rfc822 format available.

Message #26 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Wed, 26 Nov 2014 07:21:24 +0100
Hi.

Can this generation of ChangeLog handle multiple or different authors in the ChangeLog, i.e. generate something like these:

2013-05-07  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>
            Jan Djärv  <jan.h.d <at> swipnet.se>

        * Makefile.in (XRANDR_LIBS, XRANDR_CFLAGS, XINERAMA_LIBS)
        (XINERAMA_CFLAGS): New macros.
        (ALL_CFLAGS, LIBES): Use them.

How would a commit message look like to get this in the ChangeLog?

Also, how would a commit message look like if you wanted another author in the ChangeLog that is different from the one checking in?  Is it enough to set Author:?

Thanks,

	Jan D.

> 26 nov 2014 kl. 06:38 skrev Paul Eggert <eggert <at> cs.ucla.edu>:
> 
> Paul Eggert wrote:
>> combine the existing ChangeLogs (there is
>> about 24 MB worth) into a single ChangeLog.1 file at the top level.
> 
> I implemented this, along with some other fixes (notably, getting a proper copyright notice into the generated ChangeLog file), and am attaching the corresponding patches.  I would like to install this into the emacs-24 branch and then merge that into the master.
> 
> There are three patches.  Patches 1 and 3 are so large that I'm just attaching summaries here.  (Patch 1 is essentially the same as before.)  You can get the full patches temporarily from here:
> 
> http://cs.ucla.edu/~eggert/emacs/
> <0001-Rename-old-ChangeLog-files-to-prepare-for-gitlog-to-.patch><0002-Generate-a-ChangeLog-file-from-commit-logs.patch><0003-Combine-all-historical-ChangeLogs-into-ChangeLog.1.patch>





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Wed, 26 Nov 2014 07:51:01 GMT) Full text and rfc822 format available.

Message #29 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: 19113 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Tue, 25 Nov 2014 23:50:13 -0800
Jan D. wrote:
> Can this generation of ChangeLog handle multiple or different authors in the ChangeLog, i.e. generate something like these:
>
> 2013-05-07  YAMAMOTO Mitsuharu<mituharu <at> math.s.chiba-u.ac.jp>
>              Jan Djärv<jan.h.d <at> swipnet.se>
>
>          * Makefile.in (XRANDR_LIBS, XRANDR_CFLAGS, XINERAMA_LIBS)
>          (XINERAMA_CFLAGS): New macros.
>          (ALL_CFLAGS, LIBES): Use them.
>
> How would a commit message look like to get this in the ChangeLog?

You put a Co-authored-by: line somewhere in the git commit message.  E.g.:

Co-authored-by: Jan Djärv <jan.h.d <at> swipnet.se>
* Makefile.in (XRANDR_LIBS, XRANDR_CFLAGS, XINERAMA_LIBS)
(XINERAMA_CFLAGS): New macros.
(ALL_CFLAGS, LIBES): Use them.

> Also, how would a commit message look like if you wanted another author in the ChangeLog that is different from the one checking in?  Is it enough to set Author:?

Yes.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Wed, 26 Nov 2014 15:13:02 GMT) Full text and rfc822 format available.

Message #32 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Wed, 26 Nov 2014 10:12:10 -0500
> I implemented this, along with some other fixes (notably, getting a proper
> copyright notice into the generated ChangeLog file), and am attaching the
> corresponding patches.  I would like to install this into the emacs-24
> branch and then merge that into the master.

Why emacs-24?

> There are three patches.  Patches 1 and 3 are so large that I'm just
> attaching summaries here.  (Patch 1 is essentially the same as
> before.)  You can get the full patches temporarily from here:

Patch 3 sounds like a bad idea.

As for whether or not to go ahead: I can personally live with either
decision, tho I prefer dropping ChangeLog files from the VCS.  But the
benefits are likely not high enough to justify alienating other core
maintainers, so we should only go ahead if we can get their explicit
agreement first.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Wed, 26 Nov 2014 19:18:01 GMT) Full text and rfc822 format available.

Message #35 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 19113 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Wed, 26 Nov 2014 11:16:49 -0800
On 11/26/2014 07:12 AM, Stefan Monnier wrote:
> Why emacs-24?

Because it'd be a pain to deal with the development and master branches 
using different policies for ChangeLogs.  If emacs-24 stuck to the old 
policy and master used the new one, not only would developers have to 
remember which policy to use with which branch, the merging procedure 
would be complicated by the need to merge ChangeLogs developed in the 
old policy with the automatically-generated ChangeLogs of the new. There 
would inevitably be hassles with dropped logs and duplicates and so 
forth.  We have enough problems already with the merge procedure (as far 
as I can tell, it's never been done since the switch to git). So it'd be 
much better to change both branches at once, assuming emacs-24 is still 
active.

As a side benefit, I'm volunteering to do the first merge from emacs-24 
to master, which would be useful experience for us all.

> Patch 3 sounds like a bad idea.

OK, let's leave it out.

> I prefer dropping ChangeLog files from the VCS. But the benefits are 
> likely not high enough to justify alienating other core maintainers, 
> so we should only go ahead if we can get their explicit agreement first.

Please feel free to ask them.  In the long run it'd less work for 
everybody if we did the switch, and I'm volunteering to do the legwork.  
A request from you would carry more weight than one from me.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Wed, 26 Nov 2014 22:16:02 GMT) Full text and rfc822 format available.

Message #38 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Wed, 26 Nov 2014 17:15:21 -0500
>> Why emacs-24?
> Because it'd be a pain to deal with the development and master branches
> using different policies for ChangeLogs.

I guess you're right.

> We have enough problems already with the merge procedure (as far as I can
> tell, it's never been done since the switch to git).  So it'd be much better
> to change both branches at once, assuming emacs-24 is still active.

I did such a merge already.  There's nothing magical about it, and
whether it's done in Git or in Bzr makes no real difference (except that
we don't yet have the equivalent of bzrmerge.el which helped streamline
the process, of course).


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 05 Dec 2014 08:08:01 GMT) Full text and rfc822 format available.

Message #41 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 03:07:07 -0500
I think this change will lower the quality of Emacs ChangeLogs, which
are important forms of documentation; and frankly I don't even see that
it will save much work. But I'm obviously in a minority, so don't let me
stop you. I do have a list though; do whatever you like in response to it.

1) There are still things to deal with from the last big change, so I'd
appreciate it if you not do this before January at the earliest.

2) Announce the change well in advance, and make it very clear what
people need to do (ie, take much more care with their logs than before).
Put a clear set of instructions in admin/notes. Eg how will I replace `C-x
4 a', `C-c C-a' now? (Frankly I expect to keep doing that, just not
commit the ChangeLog, so as I said, I can't see that this will save any
effort). I hope the answer isn't "install vc-dwim", since Emacs is
supposed to contain all the necessary VC tools itself.

3) How will I mark a change so that it does not generate a ChangeLog?
(Examples include: NEWS edits, comment fixes, fixing a paren typo in
something I committed one second earlier.) Perhaps a "#" or somesuch in
the first char of the log? How will I do this after committing if I
forgot to so mark it at the time?

4) What if I commit something, realize it was wrong, and remove it right
away? Normally I'd delete the ChangeLog entry too.

5) Will I be able to mark a portion of a log to be excluded from the
generated ChangeLog?

6) How does the correction method work (I'm being lazy and not reading
the patch). (Since notes are editable comments associated with commits,
I like the idea of using notes to correct faulty logs.) Frankly, I
expect there to be lots of mistakes, but whatever; I'm not going to
bother to correct them anymore.

7) What dates will entries get? The commit date? This may not match the
push date. What will happen with the dates of entries merged from other
branches.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 05 Dec 2014 08:38:01 GMT) Full text and rfc822 format available.

Message #44 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 10:38:08 +0200
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Fri, 05 Dec 2014 03:07:07 -0500
> Cc: 19113 <at> debbugs.gnu.org
> 
> 4) What if I commit something, realize it was wrong, and remove it right
> away? Normally I'd delete the ChangeLog entry too.

With Git, it's useful to distinguish between "commit" and "push".  The
former can be easily fixed, since it's still only in your local clone;
use "git amend" or even "git reset".  The latter cannot be fixed,
except by running Git commands on Savannah that work directly on the
public repository, which is generally frowned upon, because others
could have pulled in-between.

> 6) How does the correction method work (I'm being lazy and not reading
> the patch).

From "gitlog-to-changelog --help:

    --amend=FILE FILE maps from an SHA1 to perl code (i.e., s/old/new/) that
                   makes a change to SHA1's commit log text or metadata.
  [...]
  In a FILE specified via --amend, comment lines (starting with "#") are ignored.
  FILE must consist of <SHA,CODE+> pairs where SHA is a 40-byte SHA1 (alone on
  a line) referring to a commit in the current project, and CODE refers to one
  or more consecutive lines of Perl code.  Pairs must be separated by one or
  more blank line.

  Here is sample input for use with --amend=FILE, from coreutils:

  3a169f4c5d9159283548178668d2fae6fced3030
  # fix typo in title:
  s/all tile types/all file types/

  1379ed974f1fa39b12e2ffab18b3f7a607082202
  # Due to a bug in vc-dwim, I mis-attributed a patch by Paul to myself.
  # Change the author to be Paul.  Note the escaped "@":
  s,Jim .*>,Paul Eggert <eggert\\\@cs.ucla.edu>,




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 05 Dec 2014 14:35:02 GMT) Full text and rfc822 format available.

Message #47 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 09:33:48 -0500
On Fri, 05 Dec 2014 03:07:07 -0500 Glenn Morris <rgm <at> gnu.org> wrote: 

GM> I think this change will lower the quality of Emacs ChangeLogs, which
GM> are important forms of documentation

For this reason and many others, I suggest blocking commits directly to
master.

Instead, people should commit to a private branch they can rewrite (git
push -f after amending a commit, for instance) and then a build system
can merge that into master when it passes ChangeLog checks (and possibly
a basic build check, and possibly maintainer approval).

This is, of course, the PR system you find on Github and such sites. It
works for thousands of projects.  I see no reason why Emacs is special.

Ted




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 05 Dec 2014 15:39:02 GMT) Full text and rfc822 format available.

Message #50 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 10:38:10 -0500
> are important forms of documentation; and frankly I don't even see that
> it will save much work. But I'm obviously in a minority, so don't let me
> stop you. I do have a list though; do whatever you like in response to it.

Good, so let's do it.

> 1) There are still things to deal with from the last big change, so I'd
> appreciate it if you not do this before January at the earliest.

Fine.

> 2) Announce the change well in advance, and make it very clear what
> people need to do (ie, take much more care with their logs than before).

Right.  the ./CONTRIBUTE file should pay special attention to it.

> Put a clear set of instructions in admin/notes. Eg how will I replace `C-x
> 4 a', `C-c C-a' now? (Frankly I expect to keep doing that, just not

Indeed, I think for now this will be the recommendation.

> 3) How will I mark a change so that it does not generate a ChangeLog?

Why bother?

> 4) What if I commit something, realize it was wrong, and remove it right
> away? Normally I'd delete the ChangeLog entry too.

I don't think it's a serious problem.  We already use "reverted last
change to <foo>" regularly.

> 5) Will I be able to mark a portion of a log to be excluded from the
> generated ChangeLog?

I don't think so, but I don't see why that would be a problem.

> 6) How does the correction method work (I'm being lazy and not reading
> the patch).

I think by and large it doesn't: it's too complicated to be of regular use.
And since it only fixes the ChangeLog but not the "git log" output, its
usefulness is rather limited.

> I'm not going to bother to correct them anymore.

That's one of the work it will save us.

> 7) What dates will entries get? The commit date? This may not match the
> push date. What will happen with the dates of entries merged from other
> branches.

They'll probably gt the commit date.  If you want more a more precise
explanation of what happened, you'll need to use the "git log"
output instead.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 05 Dec 2014 18:50:01 GMT) Full text and rfc822 format available.

Message #53 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 13:49:02 -0500
> This is, of course, the PR system you find on Github and such sites.

That's also the "patch queue management" I mentioned earlier.

> It works for thousands of projects.  I see no reason why Emacs
> is special.

Because nobody has set such a thing up (and AFAICT Savannah doesn't
have such a thing built-in, oddly enough).


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 05 Dec 2014 20:09:02 GMT) Full text and rfc822 format available.

Message #56 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 15:08:09 -0500
On Fri, 05 Dec 2014 13:49:02 -0500 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote: 

>> This is, of course, the PR system you find on Github and such sites.
SM> That's also the "patch queue management" I mentioned earlier.

Right.  I think if you call it a PR system most people will know what
you mean nowadays.

>> It works for thousands of projects.  I see no reason why Emacs
>> is special.

SM> Because nobody has set such a thing up (and AFAICT Savannah doesn't
SM> have such a thing built-in, oddly enough).

Hmm, it would require some technical work:

* targeted hydra builds for a specific branch

* a click-and-done way to merge a specific branch into master or emacs-24

* maybe a comment system

* maybe debbugs integration

* ability to review the potential ChangeLog entries that will be
  generated from the commit

Is this remotely realistic?

Ted




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 06 Dec 2014 02:28:02 GMT) Full text and rfc822 format available.

Message #59 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 06 Dec 2014 04:27:22 +0200
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> This is, of course, the PR system you find on Github and such sites.
>
> That's also the "patch queue management" I mentioned earlier.

Right. On GitHub, it's often also a decent platform for discussions.

> Because nobody has set such a thing up (and AFAICT Savannah doesn't
> have such a thing built-in, oddly enough).

It shouldn't be too hard, actually, to set up some code review tool,
such as Gerrit [0], Review Board [1] or Differential [2].

I think all of them support automatic merging of approved patches, or at
least make it reasonably easy. The last one seems to offer a lot of
options, at the cost of learning the whole Phabricator ecosystem.

What do you see as requirements for such a tool? Integration with
Savannah user database?

Do you like at least one of them?

I'd also welcome opinions from people who have experience working with
them, because honestly, I've only done in-browser code reviews
inside issue tracking tools, such as GitHub and GitLab.

[0] https://code.google.com/p/gerrit/
[1] https://www.reviewboard.org/
[2] http://phabricator.org/applications/differential/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 06 Dec 2014 04:43:01 GMT) Full text and rfc822 format available.

Message #62 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 20:42:14 -0800
I see that Stefan covered most of Glenn's points.  A quick followup:

>> 5) Will I be able to mark a portion of a log to be excluded from the
>> generated ChangeLog?
>
> I don't think so, but I don't see why that would be a problem.

We could add that capability to gitlog-to-changelog, if needed.  It shouldn't be 
hard.  I'm hoping it's not needed that much.

> I think by and large it doesn't: it's too complicated to be of regular use.
> And since it only fixes the ChangeLog but not the "git log" output, its
> usefulness is rather limited.

That's correct.  It's mainly intended to correct serious errors, e.g., 
misattribution.  To help give a feel for it, of the 3329 commits to GNU 
coreutils master since it began generating ChangeLogs automatically, only 7 have 
been corrected in coreutils' build-aux/git-log-fix file.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 06 Dec 2014 05:00:02 GMT) Full text and rfc822 format available.

Message #65 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 05 Dec 2014 23:59:34 -0500
>>> This is, of course, the PR system you find on Github and such sites.
SM> That's also the "patch queue management" I mentioned earlier.
> Right.  I think if you call it a PR system most people will know what
> you mean nowadays.

Problem is: I'm not part of "most" because for me "PR" means "Public
Relations" (aka "BS").


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 06 Dec 2014 05:07:02 GMT) Full text and rfc822 format available.

Message #68 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 06 Dec 2014 00:06:29 -0500
> What do you see as requirements for such a tool? Integration with
> Savannah user database?

I think given the current state of affair, the requirements are very
low: pretty much anything would be better than what we have now.

The only issues I can think of are that they should be installed on
machines we can control ourselves, and either they're very light on
browser resource usage or they provide some lighterweight (in terms of
resource usage) interface (such as control via email).
Being able to work with it offline is a plus.

> Do you like at least one of them?

I don't have any a-priori preference.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 06 Dec 2014 07:27:02 GMT) Full text and rfc822 format available.

Message #71 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19113 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, dgutov <at> yandex.ru
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 06 Dec 2014 09:26:30 +0200
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Sat, 06 Dec 2014 00:06:29 -0500
> Cc: 19113 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
> 
> > Do you like at least one of them?
> 
> I don't have any a-priori preference.

I suggest that Someone(TM) summarizes (on emacs-devel, I suppose) the
main features and pros/cons of using each of the alternatives, and
then we can have enough information for a decision.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 06 Dec 2014 07:40:02 GMT) Full text and rfc822 format available.

Message #74 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, rgm <at> gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 06 Dec 2014 09:40:00 +0200
> Date: Fri, 05 Dec 2014 20:42:14 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: 19113 <at> debbugs.gnu.org
> 
> >> 5) Will I be able to mark a portion of a log to be excluded from the
> >> generated ChangeLog?
> >
> > I don't think so, but I don't see why that would be a problem.
> 
> We could add that capability to gitlog-to-changelog, if needed.  It shouldn't be 
> hard.  I'm hoping it's not needed that much.

Glenn is right saying that we generally don't make ChangeLog entries
for some files in etc/, notably NEWS.  It's not a catastrophe, but it
would be a pity to see each change in NEWS to generate a trivial
ChangeLog entry.  So if this isn't hard to add to gitlog-to-changelog,
I suggest doing that.

> > I think by and large it doesn't: it's too complicated to be of regular use.
> > And since it only fixes the ChangeLog but not the "git log" output, its
> > usefulness is rather limited.
> 
> That's correct.  It's mainly intended to correct serious errors, e.g., 
> misattribution.  To help give a feel for it, of the 3329 commits to GNU 
> coreutils master since it began generating ChangeLogs automatically, only 7 have 
> been corrected in coreutils' build-aux/git-log-fix file.

I don't see a problem here: the feature already exists, and its
usefulness will have to be determined by our willingness to fix the
errors.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 06 Dec 2014 13:18:01 GMT) Full text and rfc822 format available.

Message #77 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 06 Dec 2014 08:17:58 -0500
On Fri, 05 Dec 2014 23:59:34 -0500 Stefan Monnier <monnier <at> iro.umontreal.ca> wrote: 

>>>> This is, of course, the PR system you find on Github and such sites.
SM> That's also the "patch queue management" I mentioned earlier.
>> Right.  I think if you call it a PR system most people will know what
>> you mean nowadays.

SM> Problem is: I'm not part of "most" because for me "PR" means "Public
SM> Relations" (aka "BS").

You're right it's confusing, so let's call it a "pull request" system.
Again, my point is that nowadays this is a well-known term, not that
it's technically more correct or appropriate.

Anyhow, I've followed up in emacs-devel.

Ted




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Tue, 09 Dec 2014 05:15:01 GMT) Full text and rfc822 format available.

Message #80 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Tue, 09 Dec 2014 00:14:28 -0500
Paul Eggert wrote:

> That's correct.  It's mainly intended to correct serious errors, e.g.,
> misattribution.  To help give a feel for it, of the 3329 commits to
> GNU coreutils master since it began generating ChangeLogs
> automatically, only 7 have been corrected in coreutils'
> build-aux/git-log-fix file.

coreutils has a total of 6 people with write access, all of whom are
experienced, long-time contributors.

Emacs has nearly 200 and rising, of widely varying experience, some of
whom seem to take very little care with their commit messages.

So I don't think how things work for coreutils is likely to be
representative of how they will work for Emacs.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Tue, 09 Dec 2014 06:43:01 GMT) Full text and rfc822 format available.

Message #83 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Mon, 08 Dec 2014 22:42:04 -0800
Glenn Morris wrote:
> Emacs has nearly 200 and rising, of widely varying experience, some of
> whom seem to take very little care with their commit messages.

Yes, that's a problem.  Perhaps we could have those committers work in a 
separate branch, meant for more experimental changes.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Tue, 09 Dec 2014 13:47:02 GMT) Full text and rfc822 format available.

Message #86 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Tue, 09 Dec 2014 15:46:52 +0200
On 12/06/2014 07:06 AM, Stefan Monnier wrote:
>> What do you see as requirements for such a tool? Integration with
>> Savannah user database?
>
> I think given the current state of affair, the requirements are very
> low: pretty much anything would be better than what we have now.

Okay then. Savannah integration would be a complication for me personally.

> The only issues I can think of are that they should be installed on
> machines we can control ourselves, and either they're very light on
> browser resource usage  or they provide some lighterweight (in terms of
> resource usage) interface (such as control via email).

I don't know if any of them can be considered heavy on the browser. 
Phabricator seems to be the most "slick" (and probably 
resource-intensive), but it also includes a powerful command-line tool, 
or so they say.

Here they are live:

https://git.eclipse.org/r/
http://demo.reviewboard.org/r/
https://secure.phabricator.com/

> Being able to work with it offline is a plus.

Basically, something like a layer on top of Git? That might be nice, but 
probably not in the cards.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 03 Jan 2015 01:38:03 GMT) Full text and rfc822 format available.

Message #89 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 02 Jan 2015 20:37:07 -0500
Glenn Morris wrote:

> 3) How will I mark a change so that it does not generate a ChangeLog?

I'm going to unilaterally adopt "start the commit message with '# '"
for this.

> 5) Will I be able to mark a portion of a log to be excluded from the
> generated ChangeLog?

I'm going to unilaterally adopt "start those lines of the commit message
with '# '" for this.

Only 3 lines of the entire existing Emacs commit log start with '# ',
and all 3 of those lines could happily be omitted from a generated ChangeLog.

Maybe someone will add that functionality to the generate script, and
maybe they won't. I'm going to use that markup anyway.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Mon, 12 Jan 2015 07:39:02 GMT) Full text and rfc822 format available.

Message #92 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 19113 <at> debbugs.gnu.org
Subject: Re: Generate a ChangeLog file from commit logs
Date: Sun, 11 Jan 2015 23:38:13 -0800
[Message part 1 (text/plain, inline)]
Attached is a proposed announcement for installing the patch (currently it 
suggests a changeover date of January 21, but obviously that's adjustable), 
along with updated copies of the rename patch (which should be applied to both 
emacs-24 and master branches), a followup patch for the emacs-24 branch, and a 
followup patch for the master branch.  This all tries to address some (though 
not all) the points raised.
[announcement.txt (text/plain, attachment)]
[rename.patch (text/x-patch, attachment)]
[changelog-emacs-24.patch (text/x-patch, attachment)]
[changelog-master.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Thu, 15 Jan 2015 14:59:02 GMT) Full text and rfc822 format available.

Message #95 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 15 Jan 2015 09:58:43 -0500
> Attached is a proposed announcement for installing the patch (currently it
> suggests a changeover date of January 21, but obviously that's adjustable),
> along with updated copies of the rename patch (which should be applied to
> both emacs-24 and master branches), a followup patch for the emacs-24
> branch, and a followup patch for the master branch.  This all tries to
> address some (though not all) the points raised.

If no one objects, go ahead,


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Thu, 15 Jan 2015 21:48:02 GMT) Full text and rfc822 format available.

Message #98 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 15 Jan 2015 16:46:59 -0500
Paul Eggert wrote:

> (currently it suggests a changeover date of January 21, but obviously
> that's adjustable),

I would like to see people get at least one week's notice, since this
changes a decades-old convention. This bug report doesn't count as
notice. So Jan 21 is almost too soon...

To avoid confusion, does emacs-24 need to merged to trunk just before
this change?


(I would also like to repeat my request for a dedicated announcement
mechanism for things like this. But you don't need to wait for such a
mechanism to exist before making this change.

Ref:
http://lists.gnu.org/archive/html/emacs-devel/2014-12/msg00851.html )




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 16 Jan 2015 01:29:02 GMT) Full text and rfc822 format available.

Message #101 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Thu, 15 Jan 2015 17:27:50 -0800
Glenn Morris wrote:
> I would like to see people get at least one week's notice, since this
> changes a decades-old convention. This bug report doesn't count as
> notice. So Jan 21 is almost too soon...

Yes, I'll change the date to give people a week at least.

> To avoid confusion, does emacs-24 need to merged to trunk just before
> this change?

I was planning to do a merge, yes.  My thought was to install the changes in 
emacs-24 and then skip them when merging to master, as there's a separate set of 
changes prepared for master.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 30 Jan 2015 16:36:01 GMT) Full text and rfc822 format available.

Message #104 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 30 Jan 2015 11:34:10 -0500
> I was planning to do a merge, yes.  My thought was to install the changes in
> emacs-24 and then skip them when merging to master, as there's a separate
> set of changes prepared for master.

Could we simply only make the change on master, and keep using the
ChangeLog files in `emacs-24'?

This would decouple this change from the schedule of the Emacs-24.5
release, which I think would be good.  Then we could make the change on
Valentine's day.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Fri, 30 Jan 2015 20:16:02 GMT) Full text and rfc822 format available.

Message #107 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 30 Jan 2015 12:14:53 -0800
On 01/30/2015 08:34 AM, Stefan Monnier wrote:
> Could we simply only make the change on master, and keep using the
> ChangeLog files in `emacs-24'?

Not easily, I'm afraid, as the emacs-24 branch would contain patches to 
ChangeLog files, and these files should be absent on the master branch.  
This would make merges problematic.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 31 Jan 2015 06:34:02 GMT) Full text and rfc822 format available.

Message #110 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 31 Jan 2015 01:33:33 -0500
>> Could we simply only make the change on master, and keep using the
>> ChangeLog files in `emacs-24'?
> Not easily, I'm afraid, as the emacs-24 branch would contain patches to
> ChangeLog files, and these files should be absent on the master branch.
> This would make merges problematic.

Sounds less risky than testing the new changelog-free release process on
a release which i supposed to be short, tho.  Spurious conflicts are
part of life, to some extent.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 31 Jan 2015 08:19:01 GMT) Full text and rfc822 format available.

Message #113 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 19113 <at> debbugs.gnu.org, Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 31 Jan 2015 00:18:28 -0800
Stefan Monnier wrote:
> Sounds less risky than testing the new changelog-free release process on
> a release which i supposed to be short, tho.  Spurious conflicts are
> part of life, to some extent.

OK, I'll give that a try in my private copy and see how well it works out.

There's another thing that I would like to get working better too, namely, 
rotation of commit messages into ChangeLog.1 etc. files.  So that's two birds 
that perhaps I can kill with 1.5 stones.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 31 Jan 2015 09:07:02 GMT) Full text and rfc822 format available.

Message #116 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 31 Jan 2015 10:06:09 +0100
Paul Eggert <eggert <at> cs.ucla.edu> writes:

> This would make merges problematic.

But trivial to resolve.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 21 Mar 2015 02:38:01 GMT) Full text and rfc822 format available.

Message #119 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Fri, 20 Mar 2015 19:37:01 -0700
[Message part 1 (text/plain, inline)]
I hacked on this a bit and came up with the attached files, which should be 
improvements.  'announcement.txt' is a draft email to be sent to emacs-devel 
about a week before the change.  The two patch files have the same role as 
before, and attempt to address the comments made in this thread.

It's now much easier to edit ChangeLog history: run 'make change-history' to 
prepend newer commit messages to the file ChangeLog.1 (thus marking them as 
older), edit ChangeLog.1 by hand, and then commit the result.  Once ChangeLog.1 
gets too big it should be easy to start working on ChangeLog.2.

I had trouble implementing Glenn's suggestion of using a '#' prefix to mark 
ignorable commit messages, as Git typically uses '#' for its own purposes when 
editing commit messages.  I changed the prefix to '; ' and this worked better, 
so I went with that.  It should be easy to use any string that starts with a 
character other than '#'.
[announcement.txt (text/plain, attachment)]
[0001-Rename-ChangeLogs-for-gitlog-to-changelog.patch (text/x-patch, attachment)]
[0002-Add-support-for-generating-a-ChangeLog-file-from-com.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 21 Mar 2015 08:34:01 GMT) Full text and rfc822 format available.

Message #122 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 21 Mar 2015 10:33:07 +0200
> Date: Fri, 20 Mar 2015 19:37:01 -0700
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> This change will be installed on the master branch.  Other
> branches can adopt this change whenever convenient.  The emacs-24
> branch can continue to use the old procedure, and changes to
> ChangeLog files in emacs-24 can be discarded by hand when merging
> to master.

I think we wanted to stop using ChangeLog files on the branch as well,
and that is the only reason we are waiting until after 24.5 release.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sat, 21 Mar 2015 14:39:02 GMT) Full text and rfc822 format available.

Message #125 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19113 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sat, 21 Mar 2015 10:38:34 -0400
> I think we wanted to stop using ChangeLog files on the branch as well,
> and that is the only reason we are waiting until after 24.5 release.

No, we instead decided we didn't want to wait.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19113; Package emacs. (Sun, 22 Mar 2015 23:54:02 GMT) Full text and rfc822 format available.

Message #128 received at 19113 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19113 <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Sun, 22 Mar 2015 19:53:23 -0400
Thanks for doing all that work. Shame about the '#', but life goes on.




Reply sent to Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility. (Tue, 07 Apr 2015 07:08:02 GMT) Full text and rfc822 format available.

Notification sent to Paul Eggert <eggert <at> cs.ucla.edu>:
bug acknowledged by developer. (Tue, 07 Apr 2015 07:08:02 GMT) Full text and rfc822 format available.

Message #133 received at 19113-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 19113-done <at> debbugs.gnu.org
Subject: Re: bug#19113: Generate a ChangeLog file from commit logs
Date: Tue, 07 Apr 2015 00:06:53 -0700
OK, it's April 7 by my clock, so I've installed the patch, with a few minor 
fixups (mostly having to do with allowing top-level history files ChangeLog.2, 
ChangeLog.3, etc., in the future).  I'm marking this bug as done.  No doubt 
there will be glitches in the fix, but they can be followed up with further bug 
reports.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 05 May 2015 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 8 years and 330 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.