unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: 59513@debbugs.gnu.org
Subject: [bug#59513] [PATCH] doc: contributing: Tweak the Commit Policy.
Date: Thu, 01 Dec 2022 22:44:40 +0100	[thread overview]
Message-ID: <875yeuyf1z.fsf@gnu.org> (raw)
In-Reply-To: <20221123104946.29480-1-mail@cbaines.net> (Christopher Baines's message of "Wed, 23 Nov 2022 10:49:46 +0000")

Hi!

Christopher Baines <mail@cbaines.net> skribis:

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

FWIW I like the spirit of these changes.

Now to the letter…  :-)

>  @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

Similar to zimoun’s first comment I think, I would like the beginning of
the sentence to clearly tell you whether it’s the situation you’re
interested in.  “For a minority of changes” doesn’t fit the bill in my
view.

So I would suggest something along the lines of:

  Changes should be posted to @email{guix-patches@@gnu.org}.  This
  mailing list […].  It also allows patches to be picked up and tested
  by the quality assurance robot; 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
  […] it’s OK to commit.

  As an exception, some changes considered consensual and ``trivial'' or
  ``obvious'' may instead be pushed directly.  These include: fixing
  typos, and reverting commits that caused immediate problems.

That way we state the general rule first, and the exception next.  That
also explicitly mentions how that relates to qa.guix.

Regarding the list of exceptions, I feel that these two exceptions
listed here may be less than what we may except on a day-to-day basis;
perhaps there are other things to add there, but I’m not sure what.

Would be nice to get feedback from a maintainer too.

Thanks for working on this!

Ludo’.




  parent reply	other threads:[~2022-12-01 21:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-23 10:49 [bug#59513] [PATCH] doc: contributing: Tweak the Commit Policy Christopher Baines
2022-11-23 20:27 ` zimoun
2022-11-24  8:40   ` Christopher Baines
2022-11-24 11:59     ` zimoun
2022-11-28 11:46       ` Christopher Baines
2022-12-02  9:45     ` Ludovic Courtès
2022-12-01 21:44 ` Ludovic Courtès [this message]
2022-12-12 10:33   ` Christopher Baines
2022-12-12 11:47     ` Ludovic Courtès
2022-12-08 11:20 ` [bug#59513] [PATCH v2] " Christopher Baines
2022-12-08 13:53   ` Liliana Marie Prikler
2022-12-12 10:49     ` Christopher Baines
2022-12-12 20:27       ` Liliana Marie Prikler
2022-12-13 14:06         ` Christopher Baines
2022-12-14  0:54   ` Vagrant Cascadian
2022-12-14 10:21     ` Christopher Baines
2022-12-20 10:55     ` Ludovic Courtès
2022-12-17  5:01   ` [bug#59513] [PATCH] " Maxim Cournoyer
2023-01-05  9:12   ` [bug#59513] [PATCH v2] " zimoun
2023-01-11 10:48     ` Christopher Baines
2023-01-11 10:50   ` bug#59513: " Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875yeuyf1z.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=59513@debbugs.gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).