summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorLudovic Courtès <ludo@gnu.org>2020-01-01 16:14:08 +0100
committerLudovic Courtès <ludo@gnu.org>2020-01-09 23:33:04 +0100
commit2d315cd428484537e763d7f7c676dc5fff7995f6 (patch)
tree6972dfaf87e7b2e3c23cdb76f4fa1f4f9291ec8c /doc
parenta7bde77d247ed0765f5378779d67b4668c5d7648 (diff)
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.
Diffstat (limited to 'doc')
-rw-r--r--doc/contributing.texi59
1 files changed, 59 insertions, 0 deletions
diff --git a/doc/contributing.texi b/doc/contributing.texi
index fd27f037e9..e6e6ab36c2 100644
--- a/doc/contributing.texi
+++ b/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.