From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id kJwPN99C/2Q23QAAauVa8A:P1 (envelope-from ) for ; Mon, 11 Sep 2023 18:40:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id kJwPN99C/2Q23QAAauVa8A (envelope-from ) for ; Mon, 11 Sep 2023 18:39:59 +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 8196592D6 for ; Mon, 11 Sep 2023 18:39:59 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=PeDlOto1; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694450399; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=3AwO1vy4RiOaDUhNd4lsdy4SpfHb+NKAFpByF1aJzek=; b=SiqZ9au7PH09gbuMRubGD1woUt08ouO/ROzbSo+ezktJRcgnWgJ/okmFY1pyguQ216wTbc o1p+lc32XON2FxTjntNsfqRMN4Kbnz+5ZWx4bSNbrpCWEY+utgRC0pCrusHjKS00YPJgO4 s+1wK8xx8wwtlkq+k+8v6ZwVcLcxMo/79MvAk28EM9xVE7/YsLi2pIJ0Cm3En2R17R1SEI LuNLiFZcwIDafJDzLHdQRbqce6VEbtYCWSIp8rsuWZLsm43xvK9hIP9m+htpzL5eszaofY R1iXlJA2CSRD9aPLsTuw3V7+iTxn8cONVs07VXlomEdIPZM4uomeG5wDW+pH5A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694450399; a=rsa-sha256; cv=none; b=UY+kQoL/y6l+W9+QGeO4ntCiruObUyFzeKLTEtgtHNDdncvr6YkbSCkjwhFqTVm2hNuUTt +3Y7U2+uU6xg+j7ArU6ASQ6N6ydUeCtFHuUml7osTvv/G44LPjNl+UMBq1VxrOLG0pf974 Q2ysIjW16nyh+cnY8fePLHnHlOQ0/LgAH0WHRjsiCF2ZtFOUjl6a4c/11T4o3WdRQ2NPcf AIl27jFQ5BIbKtHQWecSpVksHNvVXabF9NkpQlV7+AWzfKbYRqX6Ke2fEc2FqhM3dIwT75 XsOj/aWXD8Omo9x7MNHLH+G4PnRW+JYuZH2yBW2IQ6ilZfQk5vDxL/Roz4mqDw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=PeDlOto1; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qfjen-0008KO-0G; Mon, 11 Sep 2023 12:21:01 -0400 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 1qfjek-0008Dn-7i for bug-guix@gnu.org; Mon, 11 Sep 2023 12:20:58 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qfjej-0005m9-Vc for bug-guix@gnu.org; Mon, 11 Sep 2023 12:20:57 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qfjeo-0000zt-2a for bug-guix@gnu.org; Mon, 11 Sep 2023 12:21:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Resent-From: Simon Tournier Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 11 Sep 2023 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65391 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: "Dr. Arne Babenhauserheide" Cc: Maxim Cournoyer , 65391@debbugs.gnu.org, maximedevos@telenet.be, iyzsong@envs.net, mirai@makinata.eu, atai@atai.org, raingloom@riseup.net Received: via spool by 65391-submit@debbugs.gnu.org id=B65391.16944492253777 (code B ref 65391); Mon, 11 Sep 2023 16:21:02 +0000 Received: (at 65391) by debbugs.gnu.org; 11 Sep 2023 16:20:25 +0000 Received: from localhost ([127.0.0.1]:54615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfjeB-0000yo-O8 for submit@debbugs.gnu.org; Mon, 11 Sep 2023 12:20:25 -0400 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:38019) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qfjdx-0000y7-GP for 65391@debbugs.gnu.org; Mon, 11 Sep 2023 12:20:22 -0400 Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-31f7c87353eso430215f8f.0 for <65391@debbugs.gnu.org>; Mon, 11 Sep 2023 09:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694449199; x=1695053999; darn=debbugs.gnu.org; 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=3AwO1vy4RiOaDUhNd4lsdy4SpfHb+NKAFpByF1aJzek=; b=PeDlOto1+mIHr6QJxemKknW1J6Lz9txJPLuvDNOmvJvtub4INnPpBhhoUTGYB5SG4K BdC8DoEsLfs5CRBkL3ahg8DpH0evG0hRdO2cFgDQKDxpXuiy+bqaKW3UiFHVdEnVMAIv P44wOiXnWfGGKOvSpB+PHEt93PgGQ3CeHZBhiWyN5GaRjrFA2mUF82YL78GXKqMk77po 0+0koEVkLyNN/7mpXxvSo+pcuf0VjvGcV3HXBSTn0nH2cLLsZEDiuMBRgMcAZv9creTk CXN8GUyZJd3aPMCyLVnmtF8BycaZUvJu5/rg9E26FUqwpPMlh8vSjnzasiOM+19ot4Wb 7p7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694449199; x=1695053999; 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=3AwO1vy4RiOaDUhNd4lsdy4SpfHb+NKAFpByF1aJzek=; b=GFBLPYB2+5ozmhnzLTj8AUceYpX7oLBHIkjAOjWgSeuAdmUACV1Q90Plyhp20Tf5tM 8y2vHp+2W2uzSdte2CZXt6kd7gqdtXDGVcZwB9cV7VjuJMuvopHt2KMlH/GQvelGJ3sW AC49AXZ4lZ1IKhBA/MnxkhkAT7kk2HuvKhPGidaJgqBEadZkJITzOh/rddB/HKG8jLxw NK/LKwO7Ievj0VfPa92BPraYN549IFYjRy4k8Jgba3ESgYsX9fw5EOYuSi7qeY0qYvwO PZqLpy7Z95B8yTMDIw9oOTEcbD5A9mlLmA6JrGafbfKoq0VLv2Q2psbTZ317sMiiiFbN T1Kw== X-Gm-Message-State: AOJu0YzozESjRB4uhobEloij9lCumFttdGPtbolJ0/7sE0mHnFKlZN5K IhHD0azX2mIVSipi0PVN5i8= X-Google-Smtp-Source: AGHT+IGOHXIyhCG5B6UEhmJKzjI8MepKXFFgebgPzbDJU0GxtXiY2XH3OVyggsksQQOYs4KF2JrDgA== X-Received: by 2002:a05:6000:154e:b0:31f:85dc:110c with SMTP id 14-20020a056000154e00b0031f85dc110cmr7396192wry.0.1694449199040; Mon, 11 Sep 2023 09:19:59 -0700 (PDT) Received: from pfiuh07 ([193.48.40.241]) by smtp.gmail.com with ESMTPSA id r18-20020a5d6952000000b003141a3c4353sm10567684wrw.30.2023.09.11.09.19.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 09:19:58 -0700 (PDT) From: Simon Tournier In-Reply-To: <874jk183wx.fsf@web.de> References: <295ef8c8-574a-4169-98f3-6d9aaeb773f1@telenet.be> <6a62aced-9138-0496-fb01-d5d8e89ba8d6@telenet.be> <87h6ohc3gk.fsf@gmail.com> <87zg296z7y.fsf@gmail.com> <871qfkg65s.fsf@web.de> <87pm2ukxn5.fsf@gmail.com> <874jk183wx.fsf@web.de> Date: Mon, 11 Sep 2023 16:00:18 +0200 Message-ID: <87fs3kizd9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: bug-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: 4.21 X-Spam-Score: 4.21 X-Migadu-Queue-Id: 8196592D6 X-Migadu-Scanner: mx0.migadu.com X-TUID: 1jWFY+WtV/pZ Hi Arne, ( I have not re-read all the thread. ) On Mon, 11 Sep 2023 at 10:30, "Dr. Arne Babenhauserheide" = wrote: >> Well, I do not think that any policy will mark a package for removal on >> the first build failure. However, if the same package is still failing >> after several X or attempts, it means something is wrong. >> Marking it as a candidate for removal implies: >> >> 1. check if the failure is from CI when it builds locally, >> 2. keep a set of packages that we know they are installable. > This is a good example, but not for removing broken packages. For > perl6-xml-writer removing the package would keep breakage in Guix. > > I just checked the build, and this looks like a Guix packaging error This is exactly the effect if we have a policy. :-) Please, do not read a policy for the removal of broken packages as an automatic process. As you, I think an automatic process for removing would be a bad thing about the user experience. Maybe I misunderstand what a policy is. For me, a policy is a plan that is used as a basis for making decisions, a policy helps in reaching conclusion which then can lead to some actions. Somehow this discussion is the implementation of the policy I am proposing and that would help the maintenance, IMHO. I have manually marked this package for removal and=E2=80=A6 > that breaks the tests due to a change to some unrelated package: =E2=80=A6surprise, surprise, someone has checked. :-) A policy for removal about the broken packages would allow to know what to do. If the same package is still failing after several X or attempts, it means something is wrong. Currently, either you hit a broken package when doing some Guix operations. And that is a very poor experience, IMHO. Either one have to open the dashboard from CI [1], select some red buttons and investigate. And we can count with few fingers the number of people doing that. 1: https://ci.guix.gnu.org/eval/741273/dashboard > Disabling the tests makes the package build and work. Here is the point of my proposal to have a policy for removal of broken packages: automatically check how many times they have failed to build and automatically tag them when they are considered problematic. If no one care and these tagged packages are not fixed, then let remove them. It would drastically help in the maintenance. Otherwise, your help is very welcome in monitoring all the failures. :-) > So here, removing a package would start at the wrong place: some change > between 2021-02-01 and 2021-04-30 broke the perl6-tap-harness and we did > not detect that. Yes, that=E2=80=99s where QA should help: detect unrelated change that have= a long distance impact on unrelated packages. Changes to the branching/commit policy Christopher Baines Thu, 08 Jun 2023 15:24:37 +0100 id:87y1kuyqew.fsf@cbaines.net https://yhetil.org/guix/87y1kuyqew.fsf@cbaines.net https://lists.gnu.org/archive/html/guix-devel/2023-06 [bug#63459] [PATCH] doc: Rewrite the branching strategy. Christopher Baines Fri, 12 May 2023 08:55:20 +0100 id:f339d15842370b97558b704593848e318462b68d.1683878120.git.mail@cba= ines.net https://yhetil.org/guix/f339d15842370b97558b704593848e318462b68d.16= 83878120.git.mail@cbaines.net https://issues.guix.gnu.org/msgid/f339d15842370b97558b704593848e318= 462b68d.1683878120.git.mail@cbaines.net > This does not mean that there will never be a case in which a package > has to be removed, but given that both cases you showed are likely > self-induced breakage due to changes that should have been rejected as > breaking seemingly unrelated packages, it rather looks like the > situation where removing the package is the right way forward is the > exceptional case. We are miscommunicating. Or we have a very different vision about what should be the reliability of Guix. As a regular user, I need perl6-tap-harness, so I type =E2=80=9Cguix install perl6-tap-harness=E2=80=9D, and bang, it fails. As a regular user, I do not mind if the problem is coming from some change between 2021-02-01 and 2021-04-30 or if it comes from something else. What I want is that =E2=80=9Cguix install perl6-tap-harness=E2=80=9D= just works. Having a clear policy for removal =E2=80=93 again not an automatic removal procedure =E2=80=93 would help all, IMHO. > The norm is that our CI should have detected a problem in the commit > causing the breakage. > > Can we automatically rebuild all inheriting packages when a package gets > changed? CI builds all the commits pushed to Savannah. Not exactly all but that=E2=80=99s another story and it does not matter for this discussion. AFAIK, no one is checking that the commit they are pushing does not lead to break something. Else they would not push it I guess. ;-) Instead, it is QA that builds =E2=80=9Cpre-commit=E2=80=9C (patches). Than= ks to tireless Chris=E2=80=99s work since years, we have some tools for monitorin= g the impact of one change on the whole package set. Somehow, if I have correctly understood, QA uses the Build Coordinator to list all the derivations and then build all the new ones generated by the change. So the answer to your question is yes. :-) Aside, help is welcome for improving QA. > Also see above: in the two cases you selected, removing the package > would be the wrong path forward. Removing a package that is broken since 2021 is the good path forward. If you care about one package that is marked to be removed soon, then you fix it or raise your concern. Else it means no one care and so what is the point to keep broken packages that no one uses? >> On Wed, 30 Aug 2023 at 12:39, "Dr. Arne Babenhauserheide" wrote: >>> If a change in packages breaks my manifest, that is extremely painful. >> >> Yeah, and such rule for dealing with broken packages will be helpful for >> detecting such change and so avoid such situation. > > Since a manifest is strictly dependent on all packages defined in it, > removing a single referenced package means that the manifest is broken: > no update works anymore. No security updates come in anymore =E2=80=94 ev= en if > the package in question worked locally. This is a situation we should > not cause. Again, I am not proposing an automatic removal process but a policy. A policy could imply some news or some message saying: these packages will be removed soon because they are broken. Assuming this case: the package fails on CI and pass on your machine. Let assume you have not been enough annoyed for reporting the failure of the substitutes. Currently, the situation can stay like that for a long time. It means that each time something in the dependency graph of that package is changed, then we burn electricity for re-building it for nothing. What I am proposing is: if the same package is still failing after several X or attempts, then we mark it as =E2=80=98broken=E2=80= =99 and it becomes a candidate for a removal. People who care raise their hand. And we have a better idea about the real status. > The more important question is (serious question and *not* for assigning > blame, but to see whether we can improve processes): with the time we > already spent in this discussion, we could have fixed a lot of packages. This was exactly what I was going to answer you. :-) > Why did we not do that? I speak for myself, for many packages that are broken, my first question is: is it worth to investigate? My estimate starts with a mix between do I need them? and will the user experience be better compared to my time spent to investigate. Cheers, simon