futurile/guix-play
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
* HACKING (Commit Access): Remove.
(Contributing): Update URL of the manual.
* doc/contributing.texi (Commit Access): New section.
(Submitting Patches): Add cross reference.
This commit is contained in:
Ludovic Courtès 2020-01-01 16:14:08 +01:00
parent a7bde77d24
commit 2d315cd428
No known key found for this signature in database
GPG Key ID: 090B11993D9AEBB5
2 changed files with 60 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
HACKING
View File

@ -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]].

59
doc/contributing.texi
View File

@ -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.