Message ID | 20221208112051.5019-1-mail@cbaines.net |
---|---|
State | New |
Headers | show |
Series | [bug#59513,v2] doc: contributing: Tweak the Commit Policy. | expand |
Am Donnerstag, dem 08.12.2022 um 11:20 +0000 schrieb Christopher Baines: > 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 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. > --- > doc/contributing.texi | 41 ++++++++++++++++++----------------------- > 1 file changed, 18 insertions(+), 23 deletions(-) > > diff --git a/doc/contributing.texi b/doc/contributing.texi > index 6a8ffd6524..d2e7abba98 100644 > --- a/doc/contributing.texi > +++ b/doc/contributing.texi > @@ -1824,23 +1824,26 @@ 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 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}. > +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{number}}, where > +@var{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. I would reword that so (not significant ∧ confident ∧ qa_green) → good after 1 week whereas (not significant ∧ confident ∧ qa_unknown) → good after 2 weeks and significant changes should anyway take 2 weeks. Cheers
Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > Am Donnerstag, dem 08.12.2022 um 11:20 +0000 schrieb Christopher > Baines: >> 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 > > rigorous Thanks, I've fixed that locally now. >> 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(-) >> >> diff --git a/doc/contributing.texi b/doc/contributing.texi >> index 6a8ffd6524..d2e7abba98 100644 >> --- a/doc/contributing.texi >> +++ b/doc/contributing.texi >> @@ -1824,23 +1824,26 @@ 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 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}. >> +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{number}}, where >> +@var{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. > > I would reword that so > (not significant ∧ confident ∧ qa_green) → good after 1 week > whereas > (not significant ∧ confident ∧ qa_unknown) → good after 2 weeks > and significant changes should anyway take 2 weeks. While I like the intent here, for the moment I prefer a simpler policy. Maybe we can move in this direction when the QA tooling is more usable and reliable. Thanks, Chris
Am Montag, dem 12.12.2022 um 10:49 +0000 schrieb Christopher Baines: > > Liliana Marie Prikler <liliana.prikler@gmail.com> writes: > > > Am Donnerstag, dem 08.12.2022 um 11:20 +0000 schrieb Christopher > > Baines: > > > 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 > > > > rigorous > > Thanks, I've fixed that locally now. > > > > 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(-) > > > > > > diff --git a/doc/contributing.texi b/doc/contributing.texi > > > index 6a8ffd6524..d2e7abba98 100644 > > > --- a/doc/contributing.texi > > > +++ b/doc/contributing.texi > > > @@ -1824,23 +1824,26 @@ 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 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}. > > > +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{number}}, where > > > +@var{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. > > > > I would reword that so > > (not significant ∧ confident ∧ qa_green) → good after 1 week > > whereas > > (not significant ∧ confident ∧ qa_unknown) → good after 2 weeks > > and significant changes should anyway take 2 weeks. > > While I like the intent here, for the moment I prefer a simpler > policy. Maybe we can move in this direction when the QA tooling is > more usable and reliable. I wrote this partly with the intent of resolving an ambiguity, but I agree on the principle of having a simple policy. I take it that QA status is not that important at the moment – more that QA knows about the patch and has already started building packages? Cheers
Liliana Marie Prikler <liliana.prikler@gmail.com> writes: >> > > +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{number}}, where >> > > +@var{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. >> > >> > I would reword that so >> > (not significant ∧ confident ∧ qa_green) → good after 1 week >> > whereas >> > (not significant ∧ confident ∧ qa_unknown) → good after 2 weeks >> > and significant changes should anyway take 2 weeks. >> >> While I like the intent here, for the moment I prefer a simpler >> policy. Maybe we can move in this direction when the QA tooling is >> more usable and reliable. > > I wrote this partly with the intent of resolving an ambiguity, but I > agree on the principle of having a simple policy. I take it that QA > status is not that important at the moment – more that QA knows about > the patch and has already started building packages? I don't think the QA stuff happening is important enough make some requirements of it in the policy (yet), but, as you say, there are still benefits right now with submitting patches to guix-patches, and that's what I'm going for here.
On 2022-12-08, Christopher Baines wrote: > Only suggest waiting one week for review for simpler changes, wait two weeks > for more significant changes. ... > +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{number}}, where > +@var{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. My one concern here for things that I tend to work on is diffoscope... it has such a large dependency graph(?) because it supports so many file formats, it pulls in quite a lot for the test suites... In a week or two of changes between submission and being able to push to master, I'd worry that you could end up with a diffoscope that wouldn't build because of changes to one of it's (native-)inputs or whatnot because of changes to master in the previous week... That said, overall, I think sending everything through guix-patches is a good change, even if my lazier self pouts a little at having to deal with more process for seemingly simple things. :) live well, vagrant
Vagrant Cascadian <vagrant@debian.org> writes: > [[PGP Signed Part:Undecided]] > On 2022-12-08, Christopher Baines wrote: >> Only suggest waiting one week for review for simpler changes, wait two weeks >> for more significant changes. > ... >> +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{number}}, where >> +@var{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. > > My one concern here for things that I tend to work on is > diffoscope... it has such a large dependency graph(?) because it > supports so many file formats, it pulls in quite a lot for the test > suites... > > In a week or two of changes between submission and being able to push to > master, I'd worry that you could end up with a diffoscope that wouldn't > build because of changes to one of it's (native-)inputs or whatnot > because of changes to master in the previous week... > > > That said, overall, I think sending everything through guix-patches is a > good change, even if my lazier self pouts a little at having to deal > with more process for seemingly simple things. :) I think that's a valid concern. The QA tooling is affected similarly, in that it tests against the latest processed revision when the patch is picked up, but things could change in between the testing happening and it being merged. Remember that these time periods are only when no review takes place. My hope is that manual review can happen sooner than one or two weeks after patch submission, therefore enabling making changes more quickly. Thanks, Chris
Hi Christopher, Christopher Baines <mail@cbaines.net> writes: [...] > * doc/contributing.texi (Commit Policy): Tweak. > --- > doc/contributing.texi | 41 ++++++++++++++++++----------------------- > 1 file changed, 18 insertions(+), 23 deletions(-) > > diff --git a/doc/contributing.texi b/doc/contributing.texi > index 6a8ffd6524..d2e7abba98 100644 > --- a/doc/contributing.texi > +++ b/doc/contributing.texi > @@ -1824,23 +1824,26 @@ 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 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}. > +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{number}}, where > +@var{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. > + > +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. Like others, I like the direction of the change; the focus is changed from "trivial patches are OK to push else wait 2 weeks" to "most changes must go through the QA tooling", which should improve quality. Like Vagrant, I think it adds some friction, especially if the QA is still sometimes still unreliable and doesn't provide clear results (false positives for example), but I'm not against trying it. I guess we can try this new process, and adjust as we go (or revert to the current policy) in case something doesn't work well enough.
Howdy, Vagrant Cascadian <vagrant@debian.org> skribis: > On 2022-12-08, Christopher Baines wrote: >> Only suggest waiting one week for review for simpler changes, wait two weeks >> for more significant changes. > ... >> +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{number}}, where >> +@var{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. > > My one concern here for things that I tend to work on is > diffoscope... it has such a large dependency graph(?) because it > supports so many file formats, it pulls in quite a lot for the test > suites... > > In a week or two of changes between submission and being able to push to > master, I'd worry that you could end up with a diffoscope that wouldn't > build because of changes to one of it's (native-)inputs or whatnot > because of changes to master in the previous week... I suppose there’s always this risk. Ideally, qa.guix would either rebuild things periodically (rebasing them) or could be told to. > That said, overall, I think sending everything through guix-patches is a > good change, even if my lazier self pouts a little at having to deal > with more process for seemingly simple things. :) Right, I can sympathize. :-) I’ve done my share of direct pushes for “simple thing”, but I think there’s now evidence that sometimes simple things aren’t that simple. Waiting for a green flag from qa.guix and/or from fellow hackers might seem annoying at first, but the gains in terms of peace of mind, smooth collaboration, and overall stability are worth it. Ludo’.
Hi, On Thu, 08 Dec 2022 at 11:20, Christopher Baines <mail@cbaines.net> wrote: > 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. This would be part of the commit message, right? I would avoid the personal “I think” since it is a collective thought with some consensus (I guess). For instance, --8<---------------cut here---------------start------------->8--- Add more examples of when it can be appropriate to push changes without review, as in the case of trivial changes (as mentioned before), but also non-trivial fixes. --8<---------------cut here---------------end--------------->8--- > 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 --^ typo s/rigerious/rigorous > +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{number}}, where > +@var{number} is the number assigned by the issue tracker. Leave time To be consistent with (guix) Sending a Patch Series [1], I suggest to use @var{ISSUE_NUMBER} instead of simply @var{number}. 1: <https://guix.gnu.org/manual/devel/en/guix.html#Sending-a-Patch-Series> Aside the minor comments, all LGTM! This change appears to me a great improvement, hoping it will reduce the number of red bullets in dashboard [2]. 2: <https://ci.guix.gnu.org/eval/91795/dashboard> Cheers, simon
zimoun <zimon.toutoune@gmail.com> writes: > Hi, > > On Thu, 08 Dec 2022 at 11:20, Christopher Baines <mail@cbaines.net> wrote: > >> 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. > > This would be part of the commit message, right? Yeah, this is the commit message. > I would avoid the personal “I think” since it is a collective thought > with some consensus (I guess). For instance, > > Add more examples of when it can be appropriate to push changes without > review, as in the case of trivial changes (as mentioned before), but > also non-trivial fixes. It reads better to me with the "I think", and since it's my name on the commit, I've left it as is. >> 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 > --^ > typo > s/rigerious/rigorous Thanks, I've fixed this. >> +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{number}}, where >> +@var{number} is the number assigned by the issue tracker. Leave time > > To be consistent with (guix) Sending a Patch Series [1], I suggest to > use @var{ISSUE_NUMBER} instead of simply @var{number}. > > 1: <https://guix.gnu.org/manual/devel/en/guix.html#Sending-a-Patch-Series> Sure, I've made this change.
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
diff --git a/doc/contributing.texi b/doc/contributing.texi index 6a8ffd6524..d2e7abba98 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -1824,23 +1824,26 @@ 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 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}. +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{number}}, where +@var{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. + +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 +1858,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