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 qLjiDDBUzmMCzAAAbAwnHQ (envelope-from ) for ; Mon, 23 Jan 2023 10:32:32 +0100 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 UEn2CzBUzmOwZwEAG6o9tA (envelope-from ) for ; Mon, 23 Jan 2023 10:32:32 +0100 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 92DBBBD5F for ; Mon, 23 Jan 2023 10:32:31 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJtBB-0002Cv-8i; Mon, 23 Jan 2023 04:31:53 -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 1pJtB9-0002CY-Ro for guix-devel@gnu.org; Mon, 23 Jan 2023 04:31:51 -0500 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pJtB7-0000pk-Lt for guix-devel@gnu.org; Mon, 23 Jan 2023 04:31:51 -0500 Received: by mail-wm1-x333.google.com with SMTP id l41-20020a05600c1d2900b003daf986faaeso8037886wms.3 for ; Mon, 23 Jan 2023 01:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=EDeWuHCcfWbFqyGTszLKyj7v4WRENXhNCUNEQXoKK+c=; b=m0kdgYa0O8PwJ/0IE1W8Dyj5asiC3nwOOtNWDpsoRsI1yq1oMUdCjeFMJm9gNUMHvm L28gE5T9WwkvfeBcAXEnLjdfyFNYCGEXq6o8AmBWP6ogyS6swfgI72FNMykXsmeZXopk cIigTksTJ+h6H5YZV+gqtIlrv4k3bbYHTj6X89tguIVU6ygMupS1RAJv96pFHSkDfRE4 BCNhnoN7P3O497GQUqfadI4VuIJZ0U1BUnZS+S7GSzuKo5A0ToM/De2ysvOg5It0jOTY TT7OO2eGQ+r+hUOaGkxlv3KwbdAbQ+Etvr4MUkGYIOPk479Qy9KHU1X+RhFsRR/X4qCX 5MPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EDeWuHCcfWbFqyGTszLKyj7v4WRENXhNCUNEQXoKK+c=; b=ZIK+DsQT5QQ+YDI3adRQ3e42lVLNFq8AVkGydk+pB/88mBdY3TxvNlmlGVbqU8vbi+ 1cWNSYk6xwGIyG57Zmo6+cJJiQDLvj6ZdfTENIRPgduVuTLNcEsPjO8hbM1Ls+vkxk0g qfix3SN0759GtboenP3951HJGlI6uRGLFKHxEdugNpIqRXp9fuCA03M7uV+54hnmSccn uGMKsnvU6fdqV/AFtlcnwWnPsiweCLvPUhXDUcfuWWTp+eRWvyFXeJHfLxkEUECnc1/T UFy0Po+SJt6a2B0c212iyqkR7TttxcmQbbSmGC22dhFx+FfKzYtNZ07JUtCSKh9NyALL TV0A== X-Gm-Message-State: AFqh2kq4hwkCvV2TcfhWoi1pHMB8d8gbuqkxn6KnM1EiXDHS7uEzMQ3r w34ofo9m98PWBRqKcyN83sY86iBub5M= X-Google-Smtp-Source: AMrXdXt3k1vYypIuGskyYB73WymhhUStJhcx6G5yVAtTeWh7H/2ZiZsN+3S+JPYDsqbvlYUMx8rs2w== X-Received: by 2002:a05:600c:5120:b0:3db:21b8:5f53 with SMTP id o32-20020a05600c512000b003db21b85f53mr3968445wms.1.1674466307864; Mon, 23 Jan 2023 01:31:47 -0800 (PST) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id p19-20020a1c5453000000b003db09692364sm10092524wmi.11.2023.01.23.01.31.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jan 2023 01:31:47 -0800 (PST) From: Simon Tournier To: Andreas Enge , Christopher Baines Cc: guix-devel@gnu.org Subject: Re: Proposed changes to the commit policy (#59513) In-Reply-To: References: <87cz8no0a0.fsf@cbaines.net> <874jsq40cj.fsf@cbaines.net> <87k01k2ef5.fsf@cbaines.net> Date: Mon, 23 Jan 2023 10:24:56 +0100 Message-ID: <86k01dzjpz.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x333.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674466352; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=EDeWuHCcfWbFqyGTszLKyj7v4WRENXhNCUNEQXoKK+c=; b=qBwkEKuruXfgBJ13yfb4LQbgYalZzligEMAloSTeLtsnkevWKNOiVzlmNkXnqW2/yI/QYs 0sNcul3v22zXCwkM0h1Oydwk5JU5BvBRujzPpyWROB1z2baqXGMv6sVBANDq37zUZUEh8o vHhk5oRlLTFokIB57berxWvVmFciFBl4od71R8q0ovsctW6lg3K1d7jlyVPNMx8qHwZzGw kAFMxrYMsb52LXqrZhpD23xX/zcztP6ngs3ndsRG0V/AwUCkpSkNhuOiKcG5ggGi+a8oZX M4MxCHq10iPBb0Hds1pS6TZYQIuUlko3oD67H8+VK1us4lo512LxnvI1299JwA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=m0kdgYa0; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674466352; a=rsa-sha256; cv=none; b=bs9qv0XjJr5UOEs/sUMQp54Jj7OaOvtFDHLoHzs6tRgAavbrdnW0vmwU6NNVu+e+HJrX9d LSQRV57IhQXGX1i7egU8kngcCoone1lIWzlw7olqhRj0swN2qcWf2bUXSMjwLey8mwnNCq uRtnA5D6HdrIMRDKe27sKv3z8dvVnNn02KfdfdvXiUhgWFFl/c7+mDKNT0pengL4t8WrBv f87CyvefnGF/lpqvaUE9w5wmH+Q6j0sCitSJEmlSYObipAZSVi4N5jDDc6+EN6B38LEvp5 Ar3cWkm0/H5GSx2HDv5hTguQEVVAHbruV6MTPOkkjubRtIK0GXhzJjkUhTCK1A== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -6.25 X-Spam-Score: -6.25 X-Migadu-Queue-Id: 92DBBBD5F Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=m0kdgYa0; dmarc=pass (policy=none) header.from=gmail.com; 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-TUID: Wk5pSHJlqs1O Hi Andreas, On Sun, 22 Jan 2023 at 18:18, Andreas Enge wrote: > So I tried it once, and find the hassle offputting. It feels like doubling > the effort - after doing the real work, I need to get back to it a week > later and more or less go through the motions again (rebase the commit > and resign it, recompile Guix, build the package again just in case), > plus the debbugs effort. As mentioned here [1], it was possible to see the result of the QA for this patch here: https://qa.guix.gnu.org/issue/60931 where the patch has been built on several architectures and all the dependants too. Now, because the patch had been pushed, this result is not visible anymore. :-) 1: That=E2=80=99s said, the patch had been built for all architectures and all= the dependants too, =E2=80=9Cguix lint=E2=80=9D is applied systematically, etc. For example, =E2=80=9Cguix lint=E2=80=9D currently allows to be sure that t= he package is archived in Software Heritage; maybe this will change in the future. For what it is worth, I barely build for all the architectures the patches I submit. And I do not systematically rebuild all the dependants because sometimes I =E2=80=9Cfeel confident=E2=80=9D it is a =E2= =80=9Ctrivial=E2=80=9D change that does not deserve such rebuild. For sure, I do not remember rebuild all the dependants for all the architectures. Well, between the lines, are you suggesting that it is broken by design? :-) Other said, it would not be possible to have the dashboard [2] all green, right? Because the QA provides some green lights for a state but then you push to another state where the lights are unknown. 2: > So expect even less package updates from my part in the future... These > were the kind of instant gratification actions one could do more or less > in the background, and they have become more complex administrative > endeavours with delayed gratification. While I understand this =E2=80=9Cextra=E2=80=9C work is a burden, what woul= d you suggest to reduce the number of broken packages? Because all the red circles in the dashboard [2] is a strong issue, IMHO. When using Debian, I cross the fingers each time I run =E2=80=98apt upgrade= =E2=80=99. Using Guix, I cross the fingers each time I run =E2=80=98guix pull=E2=80=99= . Surprise, surprise. :-) Sometimes, the package that worked still works, sometimes not. This kind of example [3]: Well, for a concrete example, please give a look at [0]. A =E2=80= =9Ctrivial=E2=80=9D and apparently inoffensive update of the package =E2=80=99git=E2=80= =99 from 2.38.0 to 2.38.1 breaks some Julia packages. And, =E2=80=9Cguix refresh -l g= it=E2=80=9D does not mention these Julia packages. The package =E2=80=99git-minimal=E2= =80=99 inherits from =E2=80=99git=E2=80=99 and some Julia packages depends on =E2=80=99g= it-minimal=E2=80=99. 0: happens more than often. Give a look at the dashboard. ;-) Obviously, no blame. :-) Moreover, the complexity of all the parameters is not tractable only by manual actions, IMHO. At work, the feedback I often get is: Guix is not enough stable to daily work and users cannot spend time to investigate if they are doing something wrong or if it is broken. People are fix again and again something unrelated to their current task just because they did =E2=80=9Cgu= ix pull=E2=80=9D (for having some new packages, some security fixes, etc.). To avoid misunderstanding, I daily work with Guix and I am happy. :-) Well, as I also wrote earlier [3]. :-) =C2=AB We =E2=80=93 from core develo= pers to user just wanting the things done =E2=80=93 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? =C2=BB Maybe the current full rolling-release applied to functional package management does not scale well? 3: > Am Wed, Jan 18, 2023 at 04:54:58PM +0000 schrieb Kaelyn: >> On a side note, I'd recently discovered the flag to pass. To have a >>subject prefix like "[PATCH core-updates]" (as mentioned in the manual >>for staging and core-updates patches) instead of the default "[PATCH]", >>one can pass "--subject-prefix=3D"PATCH core-updates" to git >>format-patch.=20 > > This sounds like it could be a useful addition to the QA process. To my knowledge, it is not possible to continuously build core-updates because the project does not have enough resource (both human power and machine power). Or do you mean mentioning this option of git-format-patch under point #9 of =C2=ABSubmitting Patches=C2=BB [4]? Because this option is already in t= he manual under =C2=ABSending a Patch Series=C2=BB section: Tip: To add a prefix to the subject of your patch, you may use the =E2=80=98--subject-prefix=E2=80=99 option. The Guix project uses this= to specify that the patch is intended for a branch or repository other than the =E2=80=98master=E2=80=99 branch of . git send-email -1 -a --base=3Dauto \ --subject-prefix=3D'PATCH core-updates' \ --to=3Dguix-patches@gnu.org 4: Cheers, simon