unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: 38846@debbugs.gnu.org
Cc: "Ludovic Courtès" <ludo@gnu.org>, guix-maintainers@gnu.org
Subject: [bug#38846] [PATCH 2/4] doc: Move "Commit Access" section from 'HACKING' to the manual.
Date: Wed,  1 Jan 2020 17:34:44 +0100	[thread overview]
Message-ID: <20200101163446.5132-2-ludo@gnu.org> (raw)
In-Reply-To: <20200101163446.5132-1-ludo@gnu.org>

* HACKING (Commit Access): Remove.
(Contributing): Update URL of the manual.
* doc/contributing.texi (Commit Access): New section.
(Submitting Patches): Add cross reference.
---
 HACKING               | 47 +---------------------------------
 doc/contributing.texi | 59 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 60 insertions(+), 46 deletions(-)

diff --git a/HACKING b/HACKING
index eeea2f6311..36373278f9 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.
-- 
2.24.1

  reply	other threads:[~2020-01-01 16:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-01 16:29 [bug#38846] [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access Ludovic Courtès
2020-01-01 16:34 ` [bug#38846] [PATCH 1/4] doc: Add "Tracking Bugs and Patches" section Ludovic Courtès
2020-01-01 16:34   ` Ludovic Courtès [this message]
2020-01-01 18:08     ` [bug#38846] [PATCH 2/4] doc: Move "Commit Access" section from 'HACKING' to the manual Ricardo Wurmus
2020-01-01 16:34   ` [bug#38846] [PATCH 3/4] doc: Encourage patch review Ludovic Courtès
2020-01-01 18:09     ` Ricardo Wurmus
2020-01-01 16:34   ` [bug#38846] [PATCH 4/4] DRAFT doc: Add a cooption policy for commit access Ludovic Courtès
2020-01-01 18:15     ` Ricardo Wurmus
2020-01-02 11:20       ` Ludovic Courtès
2020-01-07 22:36         ` Maxim Cournoyer
2020-01-01 18:51     ` zimoun
2020-01-02 11:53       ` Ludovic Courtès
2020-01-02 18:35         ` zimoun
2020-01-06  9:30           ` Ludovic Courtès
2020-01-02  4:09     ` Brett Gilio
2020-01-02 11:15       ` Ricardo Wurmus
2020-01-02 11:59       ` Ludovic Courtès
2020-01-06 23:29     ` Tobias Geerinckx-Rice via Guix-patches via
2020-01-06 23:34       ` Tobias Geerinckx-Rice via Guix-patches via
2020-01-07  0:19       ` Brett Gilio
2020-01-07 11:27         ` zimoun
2020-01-09 22:39       ` bug#38846: " Ludovic Courtès
2020-01-01 18:07   ` [bug#38846] [PATCH 1/4] doc: Add "Tracking Bugs and Patches" section Ricardo Wurmus
2020-01-01 18:18   ` zimoun
2020-01-02 11:51     ` Ludovic Courtès
2020-01-02 18:40       ` zimoun
2020-01-01 18:37 ` [bug#38846] [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access Ricardo Wurmus
2020-01-06 13:13 ` Ludovic Courtès
2020-01-07 22:50   ` Marius Bakke
2020-01-06 21:44 ` zimoun
2020-01-07 11:17   ` Ludovic Courtès
2020-01-09 22:05   ` Ludovic Courtès
2020-01-10 15:49     ` zimoun
2020-01-13 10:01       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200101163446.5132-2-ludo@gnu.org \
    --to=ludo@gnu.org \
    --cc=38846@debbugs.gnu.org \
    --cc=guix-maintainers@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).