Re: On commit access, patch review, and remaining healthy

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

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