From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id CGeHHURsoGKRPgAAbAwnHQ (envelope-from ) for ; Wed, 08 Jun 2022 11:30:44 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id UFx4HERsoGJ5mAAAG6o9tA (envelope-from ) for ; Wed, 08 Jun 2022 11:30:44 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1C3931695A for ; Wed, 8 Jun 2022 11:30:44 +0200 (CEST) Received: from localhost ([::1]:33534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nys1T-0007gP-8S for larch@yhetil.org; Wed, 08 Jun 2022 05:30:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nys16-0007es-CY for guix-devel@gnu.org; Wed, 08 Jun 2022 05:30:20 -0400 Received: from ns13.heimat.it ([46.4.214.66]:45956) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nys14-0006o3-AE; Wed, 08 Jun 2022 05:30:20 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id F1BBC30087D; Wed, 8 Jun 2022 09:30:12 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER7-sracNcVf; Wed, 8 Jun 2022 09:30:11 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id F018230085C; Wed, 8 Jun 2022 09:30:10 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 835BA1B699B7; Wed, 8 Jun 2022 11:30:10 +0200 (CEST) Received: (nullmailer pid 6644 invoked by uid 1000); Wed, 08 Jun 2022 09:30:10 -0000 From: Giovanni Biscuolo To: zimoun , Ludovic =?utf-8?Q?Court=C3=A8s?= , Arun Isaac Cc: Guix Devel , GNU Guix maintainers Subject: Re: On commit access, patch review, and remaining healthy In-Reply-To: <86tu8xdlbw.fsf@gmail.com> Organization: Xelera.eu References: <87ee07m77w.fsf@gnu.org> <877d5um1oe.fsf@systemreboot.net> <87fskha2nr.fsf@gnu.org> <86tu8xdlbw.fsf@gmail.com> Date: Wed, 08 Jun 2022 11:30:09 +0200 Message-ID: <87wndrijtq.fsf@xelera.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=46.4.214.66; envelope-from=g@xelera.eu; helo=ns13.heimat.it X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1654680644; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=PBz9o4vL7fKGCBEUkOeyIn0VhfsOaLqdO9t3UL3F6OQ=; b=gii6/4MQqJh3wDI1HGmHc7gSTKGEhB0ax9zSay6u99yAO/CFlubhUHicy8+zSIkOzpWdCf um6WpwESJWn82PVOEJ/sPbCJld7eBqNsiScBWcoMDAp9DK4hna4I9i5bLaYhi1Exhjy2p9 i31/zc/FS4kO54syrAmhTTFzeMMkTlKDZszBxzQOgZAMadNh/vXv9j6dF078AziP+xEc1b uqDoDPa1IdoUKl4hfV/ivzibyraF2DZiA7emxZYWEv/pVpj587xPmL6knAdImgwaBKKGEo FokwLvD2mFP0R5ngeQ60emJZ5bsApafgLuEmwQlM8TFaoQZopiXn2+Nap6IJ+A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654680644; a=rsa-sha256; cv=none; b=b6qQrThB97q5GAnUy495gxT5wm8ZNOMTyn0bQMOunfB0whqBvjCPHCEmSrvTpdtG7Q3JYC 1n+pml4LAwZ/mMUGTYbB4S+9sJIcgZj/+WphargCNWnXsB2qBnYpg83ucxGw+Ll2oYYHAJ 52FlYmK7YYUyoPUn9U8zJ1IudoxU5Aexdnm14Nw+d7N6gK6uTC8MXMb3Fm699LRf7BaKkU yrokN5WgxW3hCb7Px5WjX8sMxyf5Z261nlNwF5A6DFfvP2IdBdP1O2ywAQXX2xvV+tqyRf UqvVGA+w5+gYZGTSswLu7ub4n5K3Z+xD5hc77U/fUU5EYRZAA/NXGqfoXi4ASg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -5.21 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 1C3931695A X-Spam-Score: -5.21 X-Migadu-Scanner: scn0.migadu.com X-TUID: rS1Xslf0z8jY --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=99d do that if you = tick all >> the boxes, you=E2=80=99re fine); > > As pointed earlier by Arun in =C2=ABPublic guix offload server=C2=BB [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 =E2=80=9Cunstable=E2=80=9D 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 =E2=80=9Cstable=E2=80= =9D and by > default user pull =E2=80=9Cstable=E2=80=9D. One week let the time to bui= ld 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 =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmKgbCEMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkS16YP/2S7qo73dyy1Skgv+7BBQ4oiwJO9SNaBJ6YlrFbG JmDvqPkRr+IASF+tNvxt8jQCo6zvUAR6EbSGvobDAXfWEzJmdoc6A10pwFC/unoa 0pZzITgMCATFZkoSvAg4yORAW2G9xocZMbSfUWTmDMK0YRx+8vV3olk+zxChqGsZ 3JpkS5Njm9FaHShG/Dd+0k2L4pZQZINX7JeTxO8Y3Pbc0Tz6MoT0GO2JXVafxDzb Xa5PQdN4S4S64usZEA4Vv5OqY6lbzxUBNuz1YsEMXxdKSOoBVhU0PZPEBaJ8Nd1H 3gvq0dQSWwbQbKgYFdcjiKO/eFbGpvRkhlCIdPGYfVQKXfL9JfPhvEhJPBzbhNm3 vnbn7O2VDRDA1iuDeHwbIsseBEkyvGSPmbJciIwQy28n4hcVE0rrcVlWBjRNGZq+ RpuCTqaU7JytB6wxvwAySu3tPQKpEMl6/wOsstjlklDrFxdhuOs0ir8tv2jdVQ3H bNJG/miHVF21DQfiKee+UORGORzAehEVc8rD8wHzx5z2Hmo/ru5Hkikhj6YQqUod RCJVFRXB1BA7iZUw7wWYY6i/87r1zLhppoJOzbnquFq6rYEce2Fy6NvfVsQYsFT6 ur5pUIdsiuHfOyv2SFa4mSnqaHR3E16LPFpaOVvE5yDjgRi3B7LMoWoqHG+0cC73 Jg7Y =89JJ -----END PGP SIGNATURE----- --=-=-=--