diff options
Diffstat (limited to 'doc/contributing.texi')
| -rw-r--r-- | doc/contributing.texi | 59 |
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. |