* CONTRIBUTE: minor improvements

* ChangeLog: cleanup entries for my recent commits

1 files changed, 24 insertions, 21 deletions

diff --git a/CONTRIBUTE b/CONTRIBUTE
index 9c904a798e5..dc6fd71624a 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -12,7 +12,8 @@ new features to add, please suggest them too -- we might like your
 idea.  Porting to new platforms is also useful, when there is a new
 platform, but that is not common nowadays.
 
-For documentation on Emacs (to understand how to implement your desired change), refer to:
+For documentation on Emacs (to understand how to implement your
+desired change), refer to:
 
 - the Emacs Manual
   http://www.gnu.org/software/emacs/manual/emacs.html
@@ -42,7 +43,8 @@ There are many ways to contribute to Emacs:
 - check if existing bug reports are fixed in newer versions of Emacs
   http://debbugs.gnu.org/cgi/pkgreport.cgi?which=pkg&data=emacs
 
-- develop a package that works with Emacs, and publish it on your own or in Gnu ELPA.
+- develop a package that works with Emacs, and publish it on your own
+  or in Gnu ELPA (see admin/notes/elpa).
 
 Here are some style and legal conventions for contributors to Emacs:
 
@@ -67,7 +69,7 @@ Emacs has additional style and coding conventions:
 
 - Remove all trailing whitespace in all source and text files.
 
-- Emacs has no convention on whether to use tabs in source code, but
+- Emacs has no convention on whether to use tabs in source code;
   please don't change whitespace in the files you edit.
 
 - Use ?\s instead of ?  in Lisp code for a space character.
@@ -151,7 +153,9 @@ When using git, commit messages should use ChangeLog format, with a
 single short line explaining the change, then an empty line, then
 unindented ChangeLog entries.  (Essentially, a commit message should
 be a duplicate of what the patch adds to the ChangeLog files.  We are
-planning to automate this better, to avoid the duplication.)
+planning to automate this better, to avoid the duplication.) You can
+use the Emacs functions log-edit-add-to-changelog or
+log-edit-insert-changelog to ease this process.
 
 ** The patch itself.
 
@@ -211,14 +215,6 @@ specify the actual author; the committer defaults to you.
 
 ** Changelog notes
 
-- Preferred form for several entries with the same content:
-
-   * help.el (view-lossage):
-   * kmacro.el (kmacro-edit-lossage):
-   * edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys.
-
-  (Rather than anything involving "ditto" and suchlike.)
-
 - Emacs generally follows the GNU coding standards when it comes to
   ChangeLogs:
   http://www.gnu.org/prep/standards/html_node/Change-Logs.html .  One
@@ -231,6 +227,14 @@ specify the actual author; the committer defaults to you.
   lowest ChangeLog that is higher than or at the same level as any file
   changed by the commit.
 
+- Preferred form for several entries with the same content:
+
+   * help.el (view-lossage):
+   * kmacro.el (kmacro-edit-lossage):
+   * edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys.
+
+  (Rather than anything involving "ditto" and suchlike.)
+
 - In ChangeLog files, there is no standard or recommended way to
   identify revisions.
 
@@ -259,8 +263,8 @@ branch.  No new features may be added to the trunk after this point,
 until the release branch is created. This freeze is announced on the
 emacs-devel mailing list, and not anywhere else.
 
-For example, "emacs-23" for Emacs 23.2 and later, "EMACS_23_1_RC" for
-23.1, "EMACS_22_BASE" for 22.x, and "EMACS_21_1_RC" for 21.x.
+The trunk branch is named "master" in git; release branches are named
+"emacs-nn" where "nn" is the major version.
 
 You must follow emacs-devel to know exactly what kinds of changes are
 allowed on what branch at any time. Announcements about the freeze
@@ -270,13 +274,12 @@ If you are fixing a bug that exists in the current release, be sure to
 commit it to the release branch; it will be merged to the master
 branch later.
 
-The exception is, if you know that the change will be difficult to
-merge to the trunk (eg because the trunk code has changed a lot).  In
-that case, it's helpful if you can apply the change to both trunk and
-branch yourself.  Indicate in the release branch commit log that there
-is no need to merge the commit to the trunk; start the commit message
-with "Backport:".  This is helpful for the person merging the release
-branch to the trunk (it is handled automatically by gitmerge.el).
+However, if you know that the change will be difficult to merge to the
+trunk (eg because the trunk code has changed a lot), you can apply the
+change to both trunk and branch yourself.  Indicate in the release
+branch commit log that there is no need to merge the commit to the
+trunk; start the commit message with "Backport:".  gitmerge.el will
+then exclude that commit from the merge to trunk.
 
 
 ** Other process information