Improve CONTRIBUTE and related files.

* CONTRIBUTE: improve; add explicit web references, move some info from
  admin/notes/* here.

* INSTALL.REPO: You can't "just run make" after a clean checkout.

* admin/notes/commits: deleted; merged into ./CONTRIBUTE

* admin/notes/repo: move commit, branch info into ./CONTRIBUTE

2 files changed, 0 insertions, 162 deletions

diff --git a/admin/notes/commits b/admin/notes/commits
deleted file mode 100644
index f33c6905d4c..00000000000
--- a/admin/notes/commits
+++ /dev/null
@@ -1,70 +0,0 @@
-HOW TO COMMIT CHANGES TO EMACS
-
-Most of these points are from:
-
-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
-
-(0) Each commit should correspond to a single change (whether spread
-    over multiple files or not).  Do not mix different changes in the
-    same commit (eg adding a feature in one file, fixing a bug in
-    another should be two commits, not one).
-
-(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 entries (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".
-
-(4) (Added in 2014) In commit comments, and ChangeLog files, it is best
-    to use ways of identifying revisions that are not dependent on a
-    particular version control system.  (At time of writing Emacs is
-    about to move to its fourth VCS and another move in the future is
-    not impossible.)  An excellent way to identify commits is by
-    quoting their summary line.  Another is with an action stamp - an
-    RFC3339 date followed by ! followed by the committer's email - for
-    example, "2014-01-16T05:43:35Z!esr@thyrsus.com". Often, "my
-    previous commit" will suffice.
-
-Followup discussion:
-http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00897.html
-http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00401.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/repo b/admin/notes/repo
index 97b4349ed65..2d4cc2a55cf 100644
--- a/admin/notes/repo
+++ b/admin/notes/repo
@@ -1,70 +1,5 @@
 NOTES ON COMMITTING TO EMACS'S REPOSITORY    -*- outline -*-
 
-* Commit metainformation
-
-** Commit in the author's name
-
-If installing changes written by someone else, commit them in their
-name, not yours.
-
-** Commit message format
-
-Commit messages should follow the conventions used in all modern
-distributed version-control systems. That is, they should consist of
-
-- A self-contained topic line, preferably no more than 75 chars long.
-
-- If other content follows the topic line, there should be a blank
-  line separating the two.
-
-- Follow the blank line with ChangeLog-like entries for the specific
-  changes you made, if any.  (As long as Emacs maintains ChangeLog
-  files, just copy the entries you made in them to the commit message
-  after the blank line.)
-
-- 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 exception is that we still sometimes quote `like-this' (as the
-  standards used to recommend) rather than 'like-this' (as they do now),
-  because `...' is so widely used elsewhere in Emacs.
-  http://lists.gnu.org/archive/html/emacs-devel/2014-05/msg00514.html
-
-** Unnecessary metainformation
-
-There is no need to make separate change log entries for files such as
-NEWS, MAINTAINERS, and FOR-RELEASE, or to indicate regeneration of
-files such as 'configure'.  "There is no need" means you don't have
-to, but you can if you want to.
-
-* Commit to the right branch
-
-Development normally takes places on the trunk.
-Sometimes specialized features are developed on separate branches
-before possibly being merged to the trunk.
-
-Development is discussed on the emacs-devel mailing list.
-
-Sometime before the release of a new major version of Emacs
-a "feature freeze" is imposed on the trunk.  No new features may be
-added after this point.  This is usually some months before the release.
-
-Shortly before the release, a release branch is created, and the
-trunk is then free for development.
-
-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.
-
-Consult emacs-devel for exactly what kinds of changes are allowed
-on what branch at any time.
-
 ** elpa
 
 This branch does not contain a copy of Emacs, but of the Emacs Lisp
@@ -72,25 +7,6 @@ package archive (elpa.gnu.org).  See admin/notes/elpa for further
 explanation, and the README file in the branch for usage
 instructions.
 
-* Install changes only on one branch, let them get merged elsewhere if needed.
-
-In particular, install bug-fixes only on the release branch (if there
-is one) and let them get synced to the trunk; do not install them by
-hand on the trunk as well.  E.g. if there is an active "emacs-24" branch
-and you have a bug-fix appropriate for the next emacs-24.x release,
-install it only on the emacs-24 branch, not on the trunk as well.
-
-Installing things manually into more than one branch makes merges more
-difficult.
-
-http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
-
-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 (when committing the branch change, indicate
-in the commit log that it should not be merged to the trunk; see below).
-
 * Installing changes from your personal branches.
 
 If your branch has only a single commit, or many different real
@@ -129,14 +45,6 @@ variable in admin/merge-gnulib before running it.
 If you remove a gnulib module, or if a gnulib module
 removes a file, then remove the corresponding files by hand.
 
-* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").
-
-Indicate in the commit log that there is no need to merge the commit
-to the trunk, e.g. start the commit message with "Backport:".  This is
-helpful for the person merging the release branch to the trunk.
-
-http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
-
 * How to merge changes from emacs-24 to trunk
 
 [The section on git merge procedure has not yet been written]