Hi, On Mon, 06 Jun 2022 at 23:43, Ludovic Courtès <l...@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....@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
