me
/
guix
Archived
1
0
Fork 0
Code

doc: contributing: Tweak the Commit Policy. 

Add more examples of when it can be appropriate to push changes without
review, as I think this can be appropriate in the case of trivial changes (as
mentioned before), but also non-trivial fixes.

No longer suggest pushing simple new packages or package upgrades (that don't
cause lots of rebuilds) without sending to guix-patches. Now there's some
automation for testing changes sent to guix-patches, sending changes there
before pushing can mean that more rigorous testing takes place and help speed
up substitutes becoming available. This is true, even if no human review takes
place.

Only suggest waiting one week for review for simpler changes, wait two weeks
for more significant changes.

Also, reorder some of the information in this section so it's grouped together
better.

* doc/contributing.texi (Commit Policy): Tweak.

Signed-off-by: Christopher Baines <mail@cbaines.net>
master
Christopher Baines 2022-11-23 10:37:11 +00:00
parent 24ad9a9a48
commit 9aa2b74198
No known key found for this signature in database
GPG Key ID: 5E28A33B0B84F577
1 changed files with 18 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
doc/contributing.texi
View File

@ -1824,23 +1824,27 @@ It additionally calls @code{make check-channel-news} to be sure
@subsection Commit Policy
If you get commit access, please make sure to follow
the policy below (discussions of the policy can take place on
If 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}).
Changes should be posted to @email{guix-patches@@gnu.org}. This mailing
list fills the patch-tracking database (@pxref{Tracking Bugs and
Patches}). It also allows patches to be picked up and tested by the
quality assurance tooling; the result of that testing eventually shows
up on the dashboard at
@indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where
@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave
time for a review, without committing anything (@pxref{Submitting
Patches}). If you didn’t receive any reply after one week (two weeks
for more significant changes), and if you're confident, it's OK to
commit.
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}.
As an exception, some changes considered ``trivial'' or ``obvious'' may
be pushed directly. This includes changes to fix typos and reverting
commits that caused immediate problems. This is subject to being
adjusted, allowing individuals to commit directly on non-controversial
changes on parts they’re familiar with.
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.,
@ -1855,14 +1859,6 @@ right before pushing:
make check-channel-news
@end example
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.
@subsection Addressing Issues
Peer review (@pxref{Submitting Patches}) and tools such as