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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

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.

-- 
Thanks,
Maxim