Hi Simon and all, just a quick note about myself: I'm (still) not contributing with patch reviews (and in general contributing too little) because in this period of my "work life" I have little time, but things will hopefully change... IMHO the curent tooling is helpful and usable with a little bit of studying (git, patch management, guix lint et al...) and effort, obviously more tools could help more users (debbugs for vim (?!?), mumi CLI) but the real hard work is not at the interface level, it's at "content" level AND at "machine power" available resources IMHO the whole process should not be automated more than this (I mean, more than making as easy as possible patch application using the reviewer preferred tools): review is a human-only job after all... let's just say reviwers are giving their fair contribution to the verification of code above stage0... at a higher level (stage99? :-) ) zimoun writes: >> 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. I can confirm that without a local offload build server Guix package development and review is unpractical: one of the first things I had to do in order to not negatively impact my working evironment was to buy a (used) machine and set it up as a local offload build server, that improved my (rare, as I said) work on guix package devel a lot. Maybe we should clarify this in the contributing section of the manual? Maybe we should warn users that to contribute you /first/ have to get enough machine CPU+memory power, possibly on an offload server (used computers can do great things)? IMHO local distributed build for patch review purposes is better than a centralized one, also as a sort of reproducibility test, no? > 1: https://yhetil.org/guix/878rynh0yq.fsf@systemreboot.net AFAIU quickly reading that thread (dated 2021-10-20) a public offload build server "as is" is too much a security risk: interested people should re-read that thread, Tobias Geerinckx-Rice explained very well the threat model. I would never use a shared offload build server or one not on bare-metal AND under my direct physical control Ludo' told us it should be possible to use a remote daemon without mutual trust between machines (id:87o8782g6q.fsf@gnu.org) and that we could have an HTTP bridge or API: what's the situation today? Anyway, I'd prefer a third build farm to cross-challenge substitutes than a public shared offload build server. :-O [...] > What remain is: not push to the production branch. :-) Maybe, we could > push to a branch “unstable” AFAIU this have little to do with patch review, unless you imply that committers can push to "unstable" with "less patch review" :-D > **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. This means that if the fix is not committed (rebased?) in that weekly timerfame the problematic patch is automatically pushed to stable without a fix; also we'll have that problematic commit in stable anyway (affecting users like me that are "pinning" specific channels?), unless we rebase "unstable"... "manually": am I wrong? With a patch-dedicated git branch the reviewer can work at his preferred pace on that patch, rebasing /when/ (not if) needed, without the risk a problematic commit will be auto-committed. ...and yes: IMHO a linear git history avoiding merges is very useful. > It reduces a bit the pressure on the committers, IMHO. It raises a bit the pressure on the maintainers, IMHO :-) IMVHO there is no effective "workarond" from proper patch review work. I understand there is a certain "entrance barrier" to become patch reviewer, but I'm afraid we cannot lower it more than the current situation except for the offload build server and more tolling options. [...] Than you founders! Thank you maintainers! Thank you committers! ...and than you Simon and all for this constructive discussions! Happy Hacking! Gio' P.S. when considering how much easy or difficult is to contribute to Guix as a software distribution we should also look at the contribution workflow model and tooling of other distributions, rolling and not-rolling (e.g. Opensuse, Debian): AFAIU we are not so bad at this compared to others (except probably the number of "package maintainers") :-D -- Giovanni Biscuolo Xelera IT Infrastructures