From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 0OWpMb1y32XwlwAA62LTzQ:P1 (envelope-from ) for ; Wed, 28 Feb 2024 18:51:57 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 0OWpMb1y32XwlwAA62LTzQ (envelope-from ) for ; Wed, 28 Feb 2024 18:51:57 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1709142717; 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=0cutLc26xbtI7TZ/dth1XRCvFaFcbHuktqhn29RrpP0=; b=KMsJFFoKalIS88/kOYdTW/1HTbx78BUYjiudFXjMuJmVFFE+ZBJcMOqc520gqeV/tMJKLd PZ1PvegHob8ZNsvfrYCef7Ak0283HCukq17DvHVKf43miPZc9r2MQ2ZJPQ1Q2S5PC6GKzG wXpsVnFtotdYOfrp1UJQ4zghn/K1frdpG53LwWe5AzKMe+Ghv+3Au66AleuAwudZesOXNV F2evPpiXcLDsBksvxkbr5wIQpP720YAmjG7sCWUgi/xEQHfZyI9B7Nt9h0PlRx6WHtIzxN 1YcARbQ6CocORAy1lag9A47oHJEssKGvHXD4Gyf4MoZJyF7PrzqLlhj94sq39A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1709142717; a=rsa-sha256; cv=none; b=hHTx/z1SWDHxXU06nQlRDNWGo8zisWNORHFGJiZCHnqPMCWVAYQwuwLWamJRArVgVBh+KJ Vo4DPL7/j0mXMHr9GkvK5HRfKxq7MCLbpBtHkiqjh03LisuppU05zpEYhgkZZ9xR2PFlEA HaCBhw9tdfGfAHTPJjb/Sc2c0Y4yX6vEXOS5UxYLf6ANbWXJw+E57xltB27ZtcV/j4NoOr qkBTAnDZ8elUBAeVzT6sgojMA5jVAkIcD4nzsmettwoHqq5lgQBIFXkWwEZAsEimw8Z+25 Sux7S0qVjzWCsQ8ss9D/89KQkRSgKR92Ev62K11LnmxMg3vmcjYznH9SALUr1A== 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 7CA2C5ED9A for ; Wed, 28 Feb 2024 18:51:57 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rfO5X-0002NX-0O; Wed, 28 Feb 2024 12:51:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfO5T-0002NA-VF; Wed, 28 Feb 2024 12:51:24 -0500 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rfO5S-000295-0U; Wed, 28 Feb 2024 12:51:23 -0500 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 7B82E30081F; Wed, 28 Feb 2024 17:51:19 +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 HTOfntJt7lPp; Wed, 28 Feb 2024 17:51:17 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.217]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id 16E6030081A; Wed, 28 Feb 2024 17:51:17 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 933AE2F0CA67; Wed, 28 Feb 2024 18:51:16 +0100 (CET) Received: (nullmailer pid 25910 invoked by uid 1000); Wed, 28 Feb 2024 17:51:16 -0000 From: Giovanni Biscuolo To: Simon Tournier , guix-devel@gnu.org Cc: help-guix@gnu.org Subject: Re: Guix Days: Patch flow discussion In-Reply-To: <87ttmaiv1j.fsf@gmail.com> Organization: Xelera.eu References: <10c82db7-6fc6-4fa0-8213-e207fa54db58@futurile.net> <87ttmaiv1j.fsf@gmail.com> Date: Wed, 28 Feb 2024 18:51:16 +0100 Message-ID: <878r344gvf.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: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -8.37 X-Spam-Score: -8.37 X-Migadu-Queue-Id: 7CA2C5ED9A X-Migadu-Scanner: mx11.migadu.com X-TUID: DaXlWD5Cy56g --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Simon, first and foremost: I'd like to say a big thank you to all the people working in the Guix community... ...and apologise if I still cannot do more to help. Simon Tournier writes: [...] > Well, let me try to quickly summarize my conclusion of the session: > > 1. We have a social/organisational problem. > > 2. We have some tooling annoyances. > > > The easy first: #2 about tools. The email workflow is often cited as > part of the issue. That=E2=80=99s a false-problem, IMHO. yes, we (as a community) already had several discussions around the false-problem named "email worfkow is too hard", I also dared to send a *very* lenghty analysis comparing the _so_called_ "pull request model" [1]= =20 Unfortunately I'm pretty sure that _this_ false issue will be cited again and again and again when discussing about "how to better help Guix maintainers" ...unless the (info "(guix) Submitting Patches") one day will finally (briefly) explain why the project is using an email based workflow and not a "so called PR workflow" (to understand why PR workflow is "so called" please read [1])=20 But all this discussion on the "email workflow" issue is more useless when considering the commit authetication mechanism _embedded_ in Guix since 2020; I recently studied this blog post: https://guix.gnu.org/en/blog/2020/securing-updates/ and it states: =2D-8<---------------cut here---------------start------------->8--- To implement that, we came up with the following mechanism and rule: 1 The repository contains a .guix-authorizations file that lists the OpenPGP key fingerprints of authorized committers. 2 A commit is considered authentic if and only if it is signed by one of the keys listed in the . guix-authorizations file of each of its parents. This is the authorization invariant. [...] The authorization invariant satisfies our needs for Guix. It has one downside: it prevents pull-request-style workflows. Indeed, merging the branch of a contributor not listed in . guix-authorizations would break the authorization invariant. It=E2=80=99s a good tradeoff for Guix because = our workflow relies on [patches carved into stone tablets] (patch tracker), but it=E2=80=99s not suitable for every project out there. =2D-8<---------------cut here---------------end--------------->8--- [patches carved into stone tablets] is a link to: https://lwn.net/Articles/702177/ =C2=ABWhy kernel development still uses email=C2=BB By Jonathan Corbet, October 1, 2016=20 an article with another ton of reasons why "all patch management tools sucks, email just sucks less. Anyway, since Guix is using the "authorization invariant" since 2020, the "email workflow" is embedded in Guix :-D Am I missing something? > Projects that use PR/MR workflow have the same problem. For instance, > Julia [1] has 896 open PR.=20 [...] > I will not speak about the channel =E2=80=99nonguix=E2=80=99 but it gives= another > clue. I will not speak about kubernetes, cited in the above cited LWN article, I will not speak about Gerrit, also cited there... [...] > To be clear, the email workflow might add burden on submitter side but I > am doubtful it is really part of the bottleneck for reviewing and > pushing submissions. Email workflow makes the reviewing workflow _extremely_ easy, provided a good MUA and a _little_ bit of self-discipline following the /easy/ guidance in (info "(guix) Reviewing the Work of Others") > Although the tools might add some unnecessary friction, the net of the > issue is IMHO #1: reviewing is just boring and time-consuming. This is the one and only reason. [...] I don't have anything to add, for now. Happy hacking! Gio' [1] id:87y1ha9jj6.fsf@xelera.eu aka https://yhetil.org/guix/87y1ha9jj6.fsf@xelera.eu/ =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmXfcpQMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkSAGoQAMz2n7TKWJ3oLzDxbt8iLXWD1SLPhVTPluQoNCfA gRWTL6XJiROBFsJOYO6kcsI5n9GRyYuuV5tajT4SG1sN5iVhFvhokAMl3tRL4ooz nicYZl8QY+fXoQn/VH9hY+SSvNyaVKEqrkMFquVC6oUFxmyQu3PmevWNZYX67WRR 2pLK6mOgb4MJfGzNDMSLqAZepv4x7+TGTIyesRizATOI4hrmR7DFKPR0epDjoJTf 5WVAE7y/1Q0lM8qkCSOEU+8/wLe4A0o8w/SnKC80mLoAI3NEjGyjD9UFLFqGBwQd ZBGouPZN7M7pt3NqBh5cLUu0HIbeqE2Xr3baMPEvy7avpCoUqZrYh+1GyjKJ6mw/ uK3GOay9HNdgFT/VB3ObnFw/szZzyapVk+bL+PAh0qg7BTcF75hnAwO4vwNNWykE nFlulmfEcX6EP2DPdIWolomnl5I291sDR77C3ys9joyYTVIFQzIXIHWJKZrIFvRU OmgekGD8Y1SXg7BpMr0ii2N9njTce9mEQfrPd+fnE2KwjZ/AY3aGMDAPM6ajCnuM CKRhVWrP2qTClz1jP+iIytEim0TBNEfoqs36U6l+6Abnn1i/OIfphyjy+GVwXgeM e1MoRwKJ9rTX/GW3ecR+lkusdKTMPegWXq01SoqutCy6xCPDggYtsSgxZ5Tv5qrq pqwN =Sbbf -----END PGP SIGNATURE----- --=-=-=--