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

[Giovanni Biscuolo]

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 <zimon.toutoune@gmail.com> 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

signature.asc
Description: PGP signature