Add bug number.

4 files changed, 70 insertions, 33 deletions

diff --git a/admin/notes/BRANCH b/admin/notes/BRANCH
index 863d86a1ed9..258fcd95566 100644
--- a/admin/notes/BRANCH
+++ b/admin/notes/BRANCH
@@ -1,11 +1,10 @@
-This file describes the CVS branch in which it is maintained.
+This file describes the bzr branch in which it is maintained.
 Everything below the line is branch-specific.
 ________________________________________________________________________
 
 This is the trunk (sometimes mistakenly called "HEAD").
-When people say "use CVS emacs", this is the branch they are talking
-about.  Likewise, a "cvs checkout" without the "-r" option results in
-this branch.
+When people say "use the development version of Emacs" or the
+"bzr version of Emacs", this is the branch they are talking about.
 
 Emacs development takes place on the trunk.  Most of the time, Emacs
 hackers add to it relatively free of constraint (aside from proper
diff --git a/admin/notes/commits b/admin/notes/commits
new file mode 100644
index 00000000000..2896328c664
--- /dev/null
+++ b/admin/notes/commits
@@ -0,0 +1,53 @@
+HOW TO COMMIT CHANGES TO EMACS
+
+http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00555.html
+From:    Miles Bader
+Subject: commit style redux
+Date:    Tue, 31 Mar 2009 12:21:20 +0900
+
+(1) Commit all changed files at once with a single log message (which
+    in CVS will result in an identical log message for all committed
+    files), not one-by-one.  This is pretty easy using vc-dir now.
+
+(2) Make the log message describe the entire changeset, perhaps
+    including relevant changelog entiries (I often don't bother with
+    the latter if it's a trivial sort of change).
+
+    Many modern source-control systems vaguely distinguish the first
+    line of the log message to use as a short summary for abbreviated
+    history listing (in arch this was explicitly called the summary,
+    but many other systems have a similar concept).  So it's nice if
+    you can format the log entry like:
+
+        SHORTISH ONE-LINE SUMMARY
+
+        MULTIPLE-LINE DETAILED DESCRIPTION POSSIBLY INCLUDING (OR
+        CONSISTING OF) CHANGELOG ENTRIES
+
+    [Even with CVS this style is useful, because web CVS browsing
+    interfaces often include the first N words of the log message of
+    the most recent commit as a short "most recent change"
+    description.]
+
+(3) Don't phrase log messages assuming the filename is known, because
+    in non-file-oriented systems (everything modern other than CVS),
+    the log listing tends to be treated as global information, and the
+    connection with specific files is less explicit.
+
+    For instance, currently I often see log messages like "Regenerate";
+    for modern source-control systems with a global log, it's better to
+    have something like "Regenerate configure".
+
+
+Followup discussion:
+http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00897.html
+
+
+PREVIOUS GUIDELINES FOR CVS
+
+For historical interest only, here is the old-style advice for CVS logs:
+http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01208.html
+
+From: Eli Zaretskii
+Subject: Re: Log messages in CVS
+Date: Sat, 29 Dec 2007 16:06:29 +0200
diff --git a/admin/notes/copyright b/admin/notes/copyright
index 40c45404f75..f4ceb273c73 100644
--- a/admin/notes/copyright
+++ b/admin/notes/copyright
@@ -24,9 +24,9 @@ the file.
 
 2. When installing code written by someone else, the ChangeLog entry
 should be in the name of the author of the code, not the person who
-installs it. I think it is helpful to put the author (if not yourself)
-in the CVS log as well; and to not install any of your own changes in
-the same commit.
+installs it.  I think it is helpful to put the author (if not yourself)
+in the commit log as well (you can also use bzr commit's "--author"
+option); and to not install any of your own changes in the same commit.
 
 3. With images, add the legal info to a README file in the directory
 containing the image.
@@ -38,17 +38,17 @@ legal notices, consider if you should add a copyright statement.
 right thing to do.
 
 
-Every non-trivial file distributed through the Emacs CVS should be
+Every non-trivial file distributed through the Emacs repository should be
 self-explanatory in terms of copyright and license. This includes
 files that are not distributed in Emacs releases (for example, the
-admin/ directory), because the whole Emacs CVS is publicly
+admin/ directory), because the whole Emacs repository is publicly
 available.
 
 The definition of triviality is a little vague, but a rule of thumb is
 that any file with less than 15 lines of actual content is trivial. If
 a file is auto-generated (eg ldefs-boot.el) from another one in the
-CVS, then it does not really matter about adding a copyright statement
-to the generated file.
+repository, then it does not really matter about adding a copyright
+statement to the generated file.
 
 Legal advice says that we could, if we wished, put a license notice
 even in trivial files, because copyright law in general looks at the
@@ -67,8 +67,8 @@ file "years" in this directory). The PDF versions of refcards etc
 should display copyright notices (an exception to the rule about
 "generated" files), but these can just display the latest year. The
 full list of years should be kept in comments in the source file. If
-these are distributed in CVS, check in a regenerated version when the
-tex files are updated.
+these are distributed in the repository, check in a regenerated
+version when the tex files are updated.
 
 Copyright changes should be propagated to any associated repositories
 (eg Gnus, MH-E), but I think in every case this happens automatically
@@ -115,7 +115,7 @@ author should be removed and the year(s) transferred to the FSF); or
 else it is possible the file should not be in Emacs at all (please
 report!).
 
-Note that it seems painfully clear that one cannot rely on CVS logs,
+Note that it seems painfully clear that one cannot rely on commit logs,
 or even ChangeLogs, for older changes. People often installed changes
 from others, without recording the true authorship.
 
@@ -555,10 +555,10 @@ system)
     obviously good):
 
 
-Is it OK to just `cvs remove' a file for legal reasons, or is
+Is it OK to just `bzr remove' a file for legal reasons, or is
 something more drastic needed? A removed file is still available from
-CVS, if suitable options are applied. (This CVS issue obviously does
-not affect a release).
+the repository, if suitable options are applied. (This issue obviously
+does not affect a release).
   rms: will ask lawyer
 
 
@@ -600,7 +600,7 @@ The EMACS_22_BASE branch was changed to GPLv3 (or later) 2007/07/25.
 Some notes:
 (see http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01431.html)
 
-1. There are some files in Emacs CVS which are not part of Emacs (eg
+1. There are some files in the Emacs tree which are not part of Emacs (eg
 those included from Gnulib). These are all copyright FSF and (at time
 of writing) GPL >= 2. rms says may as well leave the licenses of these
 alone (may import them from Gnulib again). These are:
diff --git a/admin/notes/cvslogs b/admin/notes/cvslogs
deleted file mode 100644
index ff2dcc93ff5..00000000000
--- a/admin/notes/cvslogs
+++ /dev/null
@@ -1,15 +0,0 @@
-http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01208.html
-
-From: Eli Zaretskii
-Subject: Re: Log messages in CVS
-Date: Sat, 29 Dec 2007 16:06:29 +0200
-
-I once posted a summary that I know about; see:
-
-  http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00229.html
-  http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00234.html
-  http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00312.html
-
-Richard commented here, basically approving my summary:
-
-  http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00276.html