doc: Move "Commit Access" section from 'HACKING' to the manual.

* HACKING (Commit Access): Remove.
(Contributing): Update URL of the manual.
* doc/contributing.texi (Commit Access): New section.
(Submitting Patches): Add cross reference.

HACKING

@@ -17,49 +17,4 @@ See the manual for useful hacking informations, either by running
 
   info -f doc/guix.info "Contributing"
 
-or by checking the [[http://www.gnu.org/software/guix/manual/guix.html#Contributing][web copy of the manual]].
-
-* Commit Access
-
-For frequent contributors, having write access to the repository is
-convenient.  When you deem it necessary, feel free to ask for it on the
-mailing list.  When you get commit access, please make sure to follow the
-policy below (discussions of the policy can take place on guix-devel@gnu.org.)
-
-Non-trivial patches should always be posted to guix-patches@gnu.org (trivial
-patches include fixing typos, etc.).  This mailing list fills the
-patch-tracking database at [[https://bugs.gnu.org/guix-patches]]; see
-"Contributing" in the manual for details.
-
-For patches that just add a new package, and a simple one, it’s OK to commit,
-if you’re confident (which means you successfully built it in a chroot setup,
-and have done a reasonable copyright and license auditing.)  Likewise for
-package upgrades, except upgrades that trigger a lot of rebuilds (for example,
-upgrading GnuTLS or GLib.)  We have a mailing list for commit notifications
-(guix-commits@gnu.org), so people can notice.  Before pushing your changes,
-make sure to run ‘git pull --rebase’.
-
-All commits that are pushed to the central repository on Savannah must be
-signed with an OpenPGP key, and the public key should be uploaded to your user
-account on Savannah and to public key servers, such as
-‘keys.openpgp.org’.  To configure Git to automatically sign commits,
-run:
-
-  git config commit.gpgsign true
-  git config user.signingkey CABBA6EA1DC0FF33
-
-You can prevent yourself from accidentally pushing unsigned commits to
-Savannah by using the pre-push Git hook called located at ‘etc/git/pre-push’:
-
-  cp etc/git/pre-push .git/hooks/pre-push
-
-When pushing a commit on behalf of somebody else, please add a Signed-off-by
-line at the end of the commit log message (e.g. with ‘git am --signoff’).
-This improves tracking of who did what.
-
-For anything else, please post to guix-patches@gnu.org and leave time for a
-review, without committing anything.  If you didn’t receive any reply
-after two weeks, and if you’re confident, it’s OK to commit.
-
-That last part is subject to being adjusted, allowing individuals to commit
-directly on non-controversial changes on parts they’re familiar with.
+or by checking the [[https://guix.gnu.org/manual/devel/en/html_node/Contributing.html][web copy of the manual]].

doc/contributing.texi

@@ -27,6 +27,7 @@ choice.
 * Coding Style::                Hygiene of the contributor.
 * Submitting Patches::          Share your work.
 * Tracking Bugs and Patches::   Using Debbugs.
+* Commit Access::               Pushing to the official repository.
 @end menu
 
 @node Building from Git
@@ -827,6 +828,8 @@ Development is done using the Git distributed version control system.
 Thus, access to the repository is not strictly necessary.  We welcome
 contributions in the form of patches as produced by @code{git
 format-patch} sent to the @email{guix-patches@@gnu.org} mailing list.
+Seasoned Guix developers may also want to look at the section on commit
+access (@pxref{Commit Access}).
 
 This mailing list is backed by a Debbugs instance, which allows us to
 keep track of submissions (@pxref{Tracking Bugs and Patches}).  Each
@@ -1090,3 +1093,59 @@ For example, to list all open issues on @code{guix-patches}, hit:
 
 @xref{Top,,, debbugs-ug, Debbugs User Guide}, for more information on
 this nifty tool!
+
+@node Commit Access
+@section Commit Access
+
+@cindex commit access, for developers
+For frequent contributors, having write access to the repository is
+convenient.  When you deem it necessary, feel free to ask for it on the
+mailing list.  When you get commit access, please make sure to follow
+the policy below (discussions of the policy can take place on
+@email{guix-devel@@gnu.org}).
+
+Non-trivial patches should always be posted to
+@email{guix-patches@@gnu.org} (trivial patches include fixing typos,
+etc.).  This mailing list fills the patch-tracking database
+(@pxref{Tracking Bugs and Patches}).
+
+For patches that just add a new package, and a simple one, it's OK to
+commit, if you're confident (which means you successfully built it in a
+chroot setup, and have done a reasonable copyright and license
+auditing).  Likewise for package upgrades, except upgrades that trigger
+a lot of rebuilds (for example, upgrading GnuTLS or GLib).  We have a
+mailing list for commit notifications (@email{guix-commits@@gnu.org}),
+so people can notice.  Before pushing your changes, make sure to run
+@code{git pull --rebase}.
+
+All commits that are pushed to the central repository on Savannah must
+be signed with an OpenPGP key, and the public key should be uploaded to
+your user account on Savannah and to public key servers, such as
+@code{keys.openpgp.org}.  To configure Git to automatically sign
+commits, run:
+
+@example
+git config commit.gpgsign true
+git config user.signingkey CABBA6EA1DC0FF33
+@end example
+
+You can prevent yourself from accidentally pushing unsigned commits to
+Savannah by using the pre-push Git hook called located at
+@file{etc/git/pre-push}:
+
+@example
+cp etc/git/pre-push .git/hooks/pre-push
+@end example
+
+When pushing a commit on behalf of somebody else, please add a
+@code{Signed-off-by} line at the end of the commit log message---e.g.,
+with @command{git am --signoff}.  This improves tracking of who did
+what.
+
+For anything else, please post to @email{guix-patches@@gnu.org} and
+leave time for a review, without committing anything (@pxref{Submitting
+Patches}).  If you didn’t receive any reply after two weeks, and if
+you're confident, it's OK to commit.
+
+That last part is subject to being adjusted, allowing individuals to commit
+directly on non-controversial changes on parts they’re familiar with.