[bug#59513] [PATCH v2] doc: contributing: Tweak the Commit Policy.

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

Thanks,

Chris

signature.asc
Description: PGP signature