--- Begin Message ---
|
Subject: |
[PATCH] doc: contributing: Tweak the Commit Policy. |
|
Date: |
Wed, 23 Nov 2022 10:49:46 +0000 |
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 rigerious 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.
---
doc/contributing.texi | 38 ++++++++++++++++----------------------
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 40ae33ecac..6f772961ea 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -1819,23 +1819,25 @@ 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}).
+For a minority of changes, it can be appropriate to push them directly
+without sending them for review. This includes both trivial changes
+(e.g. fixing typos) but also reverting problomatic changes and
+addressing regressions.
-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}.
+In general though, all changes should be posted to
+@email{guix-patches@@gnu.org}. This mailing list fills the
+patch-tracking database (@pxref{Tracking Bugs and Patches}). 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.
+
+That last part 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.,
@@ -1850,14 +1852,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
--
2.38.1
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [bug#59513] [PATCH v2] doc: contributing: Tweak the Commit Policy. |
|
Date: |
Wed, 11 Jan 2023 10:50:22 +0000 |
|
User-agent: |
mu4e 1.8.11; emacs 28.2 |
Christopher Baines <mail@cbaines.net> writes:
> 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 rigerious 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.
> ---
> doc/contributing.texi | 41 ++++++++++++++++++-----------------------
> 1 file changed, 18 insertions(+), 23 deletions(-)
I've now pushed this to master as
9aa2b7419854306b7ae78d4c4f7684316b834b1d, with some final tweaks.
Thanks everyone for taking a look.
Chris
signature.asc
Description: PGP signature
--- End Message ---