[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 2/3] maint: Tweak HACKING for generated ChangeLog
From: |
Eric Blake |
Subject: |
[PATCH 2/3] maint: Tweak HACKING for generated ChangeLog |
Date: |
Thu, 22 Dec 2016 15:36:45 -0600 |
Signed-off-by: Eric Blake <address@hidden>
---
HACKING | 39 +++++++++++++++++++++------------------
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/HACKING b/HACKING
index 07d7bcd..0f53bb8 100644
--- a/HACKING
+++ b/HACKING
@@ -33,16 +33,6 @@ generate the version string. Therefore, we recommend:
- Git 1.4.4+ <http://git.or.cz/>
-You may find it useful to install the git-merge-changelog merge driver:
-http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
-
-then add the following to .git/config or ~/.gitconfig:
-[merge "merge-changelog"]
- name = GNU ChangeLog merge driver
- driver = git-merge-changelog %O %A %B
-[diff "texinfo"]
- funcname = address@hidden ][\t ]*\\([^,][^,]*\\)
-
Only building the initial full source tree will be a bit painful.
Later, a plain `git pull && make' should be sufficient.
@@ -128,18 +118,32 @@ you'd use doc/Copyright/request-assign.future:
* Administrivia
+** The ChangeLog is generated from git commit comments.
+
+Your commit log should always start with a one-line summary, the second
+line should be blank, and the remaining lines are usually ChangeLog-style
+entries for all affected files. However, it's fine -- even recommended --
+to write a few lines of prose describing the change, when the summary
+and ChangeLog entries don't give enough of the big picture. Omit the
+leading TABs that you're used to seeing in a "real" ChangeLog file, but
+keep the maximum line length at 72 or smaller, so that the generated
+ChangeLog lines, each with its leading TAB, will not exceed 80 columns.
+As for the ChangeLog-style content, please follow these guidelines:
+
+ http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html
+
** If you incorporate a change from somebody on the net:
First, if it is a large change, you must make sure they have signed
the appropriate paperwork. Second, be sure to add their name and
email address to THANKS.
** Test fixes
-If a change fixes a test, mention the test in the ChangeLog entry.
-To this end, the Autotest-mode is handy.
+If a change fixes a test, mention the test in the commit log. To this
+end, the Autotest-mode is handy.
** Bug reports
-If somebody reports a new bug, mention their name in the ChangeLog
-entry and in the test case you write. Put them into THANKS.
+If somebody reports a new bug, mention their name in the commit log,
+and put them into THANKS.
The correct response to most actual bugs is to write a new test case
which demonstrates the bug. Then fix the bug, re-run the test suite,
@@ -224,10 +228,9 @@ should check the results before committing them in git.
** Set the version number
Update the version number in NEWS (with version, date, and release
-type) and ChangeLog, and mention in README whether the release is
-stable. Make sure all changes are committed, then run `git tag -s -m
-<version> -u <gpg_key> v<version>'. Do not push anything upstream at
-this point.
+type), and mention in README whether the release is stable. Make sure
+all changes are committed, then run `git tag -s -m <version> -u
+<gpg_key> v<version>'. Do not push anything upstream at this point.
** Update configure
As much as possible, make sure to release an Autoconf that uses
--
2.9.3