all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>,
	"Arun Isaac" <arunisaac@systemreboot.net>
Cc: Guix Devel <guix-devel@gnu.org>,
	GNU Guix maintainers <guix-maintainers@gnu.org>
Subject: Re: On commit access, patch review, and remaining healthy
Date: Tue, 07 Jun 2022 08:44:19 +0200	[thread overview]
Message-ID: <86tu8xdlbw.fsf@gmail.com> (raw)
In-Reply-To: <87fskha2nr.fsf@gnu.org>

Hi,

On Mon, 06 Jun 2022 at 23:43, Ludovic Courtès <ludo@gnu.org> wrote:

> I can think of two ways to reassure committers:
>
>   1. By having clear reviewer check lists (you’d do that if you tick all
>      the boxes, you’re fine);

As pointed earlier by Arun in «Public guix offload server» [1], this
check list would imply some rebuilds and it can be difficult depending
on the resource at hand by the committer who reviews.

1: https://yhetil.org/guix/878rynh0yq.fsf@systemreboot.net


>   2. By improving automation—nothing new here: if there was a tick that
>      says “applies without merge conflicts” and another one that read
>      “builds fine”, anyone could lightheartedly hit the “merge” button.

From my understanding, one of the issue is where the committers push vs
where the users pull.  Basically, the push happen on master and the
changes are directly available to the users.  On one hand, it is nice
because the things are delivered faster.  On the other hand, a tiny
change can break many workflows – it is or could be a reason for
refraining pushing.

More eyes who review help, for sure.  But it is not straightforward as
we are often discussing. :-) More tools can also help, but AFAIK,
nothing is fully ready right now.

What remain is: not push to the production branch. :-) Maybe, we could
push to a branch “unstable” **automatically** merged every week to the
branch “stable” and by default user pull “stable”.  One week let the
time to build by the CI, check everything is fine and fix otherwise.  It
reduces a bit the pressure on the committers, IMHO.

We – from core developers to user just wanting the things done – are all
pulling the same branch.  This branch cannot satisfy in the same time
all the constraints; is the current push/pull branch model satisfying
the best optimum with the resource and tools at hand?


Cheers,
simon


  reply	other threads:[~2022-06-07  7:01 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02 15:10 On commit access, patch review, and remaining healthy Ludovic Courtès
2022-06-02 20:22 ` Brian Cully via Development of GNU Guix and the GNU System distribution.
2022-06-03 19:37   ` Ludovic Courtès
2022-06-03 21:17     ` Ricardo Wurmus
2022-06-04 12:32     ` [bug#55794] doc: Add debbugs-gnu-guix command for Emacs Oleg Pykhalov
2022-06-07  7:08     ` On commit access, patch review, and remaining healthy Efraim Flashner
2022-06-07 15:11       ` Ludovic Courtès
2022-06-08 11:39         ` Efraim Flashner
2022-06-08 21:10           ` Ludovic Courtès
2022-06-20 12:53         ` Hartmut Goebel
2022-06-21 15:44           ` zimoun
2022-06-22  9:19             ` Munyoki Kilyungi
2022-06-02 20:32 ` Pier-Hugues Pellerin
2022-06-03 19:42   ` Ludovic Courtès
2022-06-02 21:35 ` Luis Felipe
2022-06-03  8:22   ` Feed on specific topic (public-inbox?) zimoun
2022-06-03 10:51     ` zimoun
2022-06-06 12:11 ` On commit access, patch review, and remaining healthy Arun Isaac
2022-06-06 21:43   ` Ludovic Courtès
2022-06-07  6:44     ` zimoun [this message]
2022-06-08  9:30       ` Giovanni Biscuolo
2022-06-14 12:24         ` zimoun
2022-06-15  7:01           ` Arun Isaac
2022-06-15  9:19             ` Ludovic Courtès
2022-06-19  6:55             ` Paul Jewell
2022-06-20 12:11               ` Arun Isaac
2022-06-15 15:11           ` Giovanni Biscuolo
2022-06-08 10:54     ` Giovanni Biscuolo
2022-06-09 19:55     ` Arun Isaac
2022-06-08  9:49   ` Giovanni Biscuolo
2022-06-09 19:50     ` Arun Isaac
2022-06-10 12:27       ` Giovanni Biscuolo
2022-06-10 15:03         ` Efraim Flashner
2022-06-10 16:10           ` Giovanni Biscuolo
2022-06-10 16:26           ` Giovanni Biscuolo
2022-06-10 15:03         ` Maxime Devos
2022-06-11  4:13         ` Thiago Jung Bauermann
2022-06-11  9:37           ` Ludovic Courtès
2022-06-14 11:54           ` zimoun
2022-06-14 15:54             ` Maxim Cournoyer
2022-06-15  6:46               ` Arun Isaac
2022-06-13 12:19         ` Arun Isaac
     [not found] <mailman.12124.1654864076.1231.guix-devel@gnu.org>
2022-06-12  8:18 ` Ricardo Wurmus
2022-06-12  9:42   ` Giovanni Biscuolo
2022-06-12 13:10     ` Maxime Devos
2022-06-13  9:34       ` Giovanni Biscuolo
2022-06-13 10:48         ` Maxime Devos
2022-06-13 14:21           ` Giovanni Biscuolo
2022-06-12  8:21 ` Ricardo Wurmus

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

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

  git send-email \
    --in-reply-to=86tu8xdlbw.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=arunisaac@systemreboot.net \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@gnu.org \
    --cc=ludo@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.