unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: zimoun <zimon.toutoune@gmail.com>
Cc: 59513@debbugs.gnu.org
Subject: [bug#59513] [PATCH] doc: contributing: Tweak the Commit Policy.
Date: Thu, 24 Nov 2022 08:40:59 +0000	[thread overview]
Message-ID: <871qps20fa.fsf@cbaines.net> (raw)
In-Reply-To: <86tu2pfmbv.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]


zimoun <zimon.toutoune@gmail.com> writes:

> Hi Chris,

Hey! Thanks for taking a look.

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

chroot setup doesn't really make sense to me, I'm not sure why that
needs specifying (like do we not want things for the Hurd pushing, since
the guix-daemon doesn't support build isolation there yet)?

Also, this guidance is very general, and I think it should be applicable
to all changes. We already trust people with commit access to know what
needs doing, I see this documentation as more about how, so I'd prefer
not to try and put a list here.

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

My reason for changing this is that I think waiting two weeks after
sending a simple patch is unreasonable. The value from the automated
testing will come after one to two days, I just put a week to avoid
changing it too much, but maybe the lower bound should be two days.

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

Why though? What do we expect people with commit access to do when they
read about that here?

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

That seems fine to me, I think "everything" maybe carries more weight
than "anything" though.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

  reply	other threads:[~2022-11-24  9:00 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 [this message]
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
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=871qps20fa.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=59513@debbugs.gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /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).