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

[zimoun <zimon.toutoune@gmail.com>]

Hi Chris,

On Wed, 23 Nov 2022 at 10:49, Christopher Baines <mail@cbaines.net> wrote:

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

I would write:

        … changes), and if you're confident (which means you
        successfully built it in a chroot setup, and have done a
        reasonable copyright and license auditing), it’s OK to commit.

and I would keep the «two weeks» instead of the «one week except».

I think it is also useful to provide the information about commit
notifications (guix-commits mailing list).

For what it is worth, I find clearer the structure,

    For patches that …
    For anything else, …

or

    For a minority of changes, …
    For anything else, …

than «In general though, all changes …».

Cheers,
simon