diff options
| -rw-r--r-- | HACKING | 47 | ||||
| -rw-r--r-- | doc/contributing.texi | 59 |
2 files changed, 60 insertions, 46 deletions
diff --git a/HACKING b/HACKING index deb41a9cef..aaa673fc93 100644 --- a/HACKING +++ b/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]]. 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. |