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

1 files changed, 145 insertions, 37 deletions

diff --git a/CONTRIBUTE b/CONTRIBUTE
index b07b6c66afe..9c904a798e5 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -12,36 +12,65 @@ 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 how to develop Emacs changes, refer to the Emacs
-Manual and the Emacs Lisp Reference Manual (both included in the Emacs
-distribution).  The web pages in http://www.gnu.org/software/emacs
-contain additional information.
+For documentation on Emacs (to understand how to implement your desired change), refer to:
 
-You may also want to submit your change so that can be considered for
-inclusion in a future version of Emacs (see below).
+- the Emacs Manual
+  http://www.gnu.org/software/emacs/manual/emacs.html
+  (info "(Emacs)Top")
 
-If you don't feel up to hacking Emacs, there are many other ways to
-help.  You can answer questions on the mailing lists, write
-documentation, find and report bugs, check if existing bug reports
-are fixed in newer versions of Emacs, contribute to the Emacs web
-pages, or develop a package that works with Emacs.
+- the Emacs Lisp Reference Manual
+  http://www.gnu.org/software/emacs/manual/elisp.html
+  (info "(elisp)Top")
+
+- http://www.gnu.org/software/emacs
+
+- http://www.emacswiki.org/
+
+There are many ways to contribute to Emacs:
+
+- implement a new feature, and submit a patch (see "Submitting
+  Patches" below).
+
+- answer questions on the Emacs user mailing list
+  https://lists.gnu.org/mailman/listinfo/help-gnu-emacs
+
+- write documentation, either on the wiki, or in the Emacs source
+  repository (see "Submitting Patches" below)
+
+- find and report bugs; use M-x report-emacs-bug
+
+- 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.
 
 Here are some style and legal conventions for contributors to Emacs:
 
 
 * Coding Standards
 
-Contributed code should follow the GNU Coding Standards.
+Contributed code should follow the GNU Coding Standards
+(http://www.gnu.org/prep/standards/ - may also be available in info on
+your system).
 
 If it doesn't, we'll need to find someone to fix the code before we
 can use it.
 
-Emacs has certain additional style and coding conventions.
+Emacs has additional style and coding conventions:
+
+- the "Tips" Appendix in the Emacs Lisp Reference
+  http://www.gnu.org/software/emacs/manual/html_node/elisp/Tips.html
+  (info "(elisp)Tips").
 
-Ref: http://www.gnu.org/prep/standards/
-Ref: GNU Coding Standards Info Manual
-Ref: The "Tips" Appendix in the Emacs Lisp Reference.
+- Avoid using `defadvice' or `eval-after-load' for Lisp code to be
+  included in Emacs.
 
+- Remove all trailing whitespace in all source and text files.
+
+- Emacs has no convention on whether to use tabs in source code, but
+  please don't change whitespace in the files you edit.
+
+- Use ?\s instead of ?  in Lisp code for a space character.
 
 * Copyright Assignment
 
@@ -75,19 +104,18 @@ patches) over all your contributions.
 
 * Getting the Source Code
 
-The latest version of the Emacs source code can be downloaded from the
-Savannah web site.  It is important to write your patch based on the
-latest version.  If you start from an older version, your patch may be
-outdated (so that maintainers will have a hard time applying it), or
-changes in Emacs may have made your patch unnecessary.
+The current working version of the Emacs source code is stored in a
+git repository on the Savannah web site
+(http://savannah.gnu.org/projects/emacs).  It is important to write
+your patch based on the current working version.  If you start from an
+older version, your patch may be outdated (so that maintainers will
+have a hard time applying it), or changes in Emacs may have made your
+patch unnecessary.
 
 After you have downloaded the repository source, you should read the file
 INSTALL.REPO for build instructions (they differ to some extent from a
 normal build).
 
-Ref: http://savannah.gnu.org/projects/emacs
-
-
 * Submitting Patches
 
 Every patch must have several pieces of information before we
@@ -112,11 +140,12 @@ For new features, a description of the feature and your implementation.
 A ChangeLog entry as plaintext (separate from the patch).
 
 See the existing ChangeLog files for format and content.  Note that,
-unlike some other projects, we do require ChangeLogs also for
+unlike some other projects, we do require ChangeLogs for
 documentation, i.e. Texinfo files.
 
 Ref: "Change Log Concepts" node of the GNU Coding Standards Info
 Manual, for how to write good log entries.
+http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html
 
 When using git, commit messages should use ChangeLog format, with a
 single short line explaining the change, then an empty line, then
@@ -154,27 +183,106 @@ Making cosmetic formatting changes (indentation, etc) makes it harder
 to see what you have really changed.
 
 
-* Coding style and conventions.
+* Supplemental information for Emacs Developers.
 
-** Mandatory reading:
+An "Emacs Developer" is someone who contributes a lot of code or
+documentation to the Emacs repository.
 
-The "Tips and Conventions" Appendix of the Emacs Lisp Reference.
+** Write access to the Emacs repository.
 
-** Avoid using `defadvice' or `eval-after-load' for Lisp code to be
-included in Emacs.
+Once you become a frequent contributor to Emacs, we can consider
+giving you write access to the version-control repository. Request
+access on the emacs-devel@gnu.org mailing list.
 
-** Remove all trailing whitespace in all source and text files.
+** Using the Emacs repository
 
-** Use ?\s instead of ?  in Lisp code for a space character.
+Emacs uses git for the source code repository.
 
+See http://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs to get
+started, and http://www.emacswiki.org/emacs/GitForEmacsDevs for more
+advanced information.
 
-* Supplemental information for Emacs Developers.
+Alternately, see admin/notes/git-workflow.
 
-** Write access to the Emacs repository.
+If committing changes written by someone else, make the ChangeLog
+entry in their name, not yours. git distinguishes between the author
+and the committer; use the --author option on the commit command to
+specify the actual author; the committer defaults to you.
 
-Once you become a frequent contributor to Emacs, we can consider
-giving you write access to the version-control repository.
+** 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
+  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.
+
+- There are multiple ChangeLogs in the emacs source; roughly one per
+  high-level directory. The ChangeLog entry for a commit belongs in the
+  lowest ChangeLog that is higher than or at the same level as any file
+  changed by the commit.
+
+- In ChangeLog files, there is no standard or recommended way to
+  identify revisions.
+
+  One way to identify revisions 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.
+
+- 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.
+
+** branches
+
+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, to prepare for creating a release
+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.
+
+You must follow emacs-devel to know exactly what kinds of changes are
+allowed on what branch at any time. Announcements about the freeze
+(and other important events) will contain "ANNOUNCE" in the subject.
+
+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).
+
+
+** Other process information
 
+See all the files in admin/notes/* . In particular, see
+admin/notes/newfile, see admin/notes/repo.
 
 ** Emacs Mailing lists.
 
@@ -189,7 +297,7 @@ by following links from http://savannah.gnu.org/mail/?group=emacs .
 
 ** Document your changes.
 
-Any change that matters to end-users should have a NEWS entry.
+Any change that matters to end-users should have an entry in etc/NEWS.
 
 Think about whether your change requires updating the documentation
 (both manuals and doc-strings).  If you know it does not, mark the NEWS