From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id sLS5MYap7mTjWgAA9RJhRA:P1 (envelope-from ) for ; Wed, 30 Aug 2023 04:29:26 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id sLS5MYap7mTjWgAA9RJhRA (envelope-from ) for ; Wed, 30 Aug 2023 04:29:26 +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 88D0E55662 for ; Wed, 30 Aug 2023 04:29:26 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=FMawEtq1; 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=1693362566; 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=40SkW82ncHwP+KVvswTqPqt7YlqlCAkCtDrF2m7aetM=; b=RcT2aLWKUexhka/SVCYsws9j2eVUnWutCVENWHYchqIRkCzD8Gs628ujy+EkLUbYbTKxvJ mTHi4m3E38nIcrlCYzdwB2PGojJICzc/kH2357wzEEQLd7+wL8Tk3APgV9SVl5Dnr5jZqS 9j3V4P4ncfask2umK5jZhCaTSl77prMBw4T+3UCQlphaKZyJ2/9JEEpFOQwEjQE6kQcmiH T/Si5zADyK/o01unfnMpWH0hCleLZ9LKxyDExXd14Q4s9CPxZ33LZwUMfWZ9D/siGFtw7/ n8+oODM9PLHxXYnT6H3wQ7hyJOakT5dug45jYroz4VY7SCMXq/swMHFCvjOozg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693362566; a=rsa-sha256; cv=none; b=CtcCzugBm52YUheS6H/nQM5DnvIzic0yfqqTTn5n5A624JmzmWYZ5KK+O/mQEuMlHR+0yU cb2f9OxRb7qvE12u/Hw8qCUk4RTusJAqN26pf9xJTBCdy4XJ6dYE6mi04fVudEnNgI0ufB IImZztDb9DVIvDT3hKv5yTu4QcPcbg22Sd7xzSnZis6bdHbw9h31yZuzR+4I3BgH7C7422 ihm5OjmM+Tn8ZpW9Ce8l1fyIC5X6a14rV7aDCeZBEuTiYYtt/uCkZAUY4tkktoBdqwSktM lo4uFHeRkXgQiADaXrbZa20QEy4hMjjK7QCyoJN4YieRbo+Oc+Nc9tSl7ZWrPw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=FMawEtq1; 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 1qbAxG-00070q-46; Tue, 29 Aug 2023 22:29:16 -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 1qbAwx-0006j9-9Q for bug-guix@gnu.org; Tue, 29 Aug 2023 22:28:56 -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 1qbAww-0002Wt-Vf for bug-guix@gnu.org; Tue, 29 Aug 2023 22:28:54 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qbAx3-0007un-V6 for bug-guix@gnu.org; Tue, 29 Aug 2023 22:29:01 -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: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 30 Aug 2023 02:29:01 +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: Maxime Devos Cc: Andy Tai , Bruno Victal , Csepp , =?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?= , 65391@debbugs.gnu.org Received: via spool by 65391-submit@debbugs.gnu.org id=B65391.169336250030373 (code B ref 65391); Wed, 30 Aug 2023 02:29:01 +0000 Received: (at 65391) by debbugs.gnu.org; 30 Aug 2023 02:28:20 +0000 Received: from localhost ([127.0.0.1]:51880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbAwN-0007tp-K6 for submit@debbugs.gnu.org; Tue, 29 Aug 2023 22:28:20 -0400 Received: from mail-qk1-x729.google.com ([2607:f8b0:4864:20::729]:62727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbAwK-0007ta-6X for 65391@debbugs.gnu.org; Tue, 29 Aug 2023 22:28:18 -0400 Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-76da819edc7so19465385a.1 for <65391@debbugs.gnu.org>; Tue, 29 Aug 2023 19:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693362483; x=1693967283; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=40SkW82ncHwP+KVvswTqPqt7YlqlCAkCtDrF2m7aetM=; b=FMawEtq12fqBhcCCxVWNtvX90Shju4Zka/uk4016FsF5u6HOKH32W+FVCitBuGIqZY jhrw3jDhQLhHEKsYWnjfR16JA3wSa1bvTzNbpP8bIEk0fTgg1WFoymtHec5lrU7wd7LJ MgPyzw5vPl86AP/dsndyZEBbkDe5BOHCwKjyFwTMLYxb0t/jSZKNQwQch5IBgUCCeXmc Qf6zj8u3WqYQegQkRnrf65l6SgVcHa/+LS/SEyRqDaL8Y1UFomZuNxjkyevkkzm99c3W LPPe/Gyf1A/p+eU1nVFtTzCb8WkUxUhRN87LZgsZMZ3k4Rj3xLeX3b+gFfeHZWx5wq0m Y+Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693362483; x=1693967283; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=40SkW82ncHwP+KVvswTqPqt7YlqlCAkCtDrF2m7aetM=; b=KnG9SuE657ne9DlQYyBlaOdTVZ3AvCILjWJS/ceD3GsDID/Q53As371utYRAnrxSr6 2e6fpyxFFx8laAjiS1pobonV3snZY+iy4YMslRne0mVKBFlySZIGxFC6tL2mdPO2qWbQ 4ccg7hu0nK55WLoq1pLsL2AFv9u3s8WzWCpDqF49RcSf5MDugjyRiPM4F9aUuQ4Y0AUG qeXiZCMA0l+AIojsLShoHS/RpWqrauSH6WNadZuBFdi6U6hL+8IvaysJ+399jl38aA2P 3DqiuzKiisNiEE/v20H+yX1d/sPLyCKqtgUx1djlVOVB+FkrKU5/rlE6uffp/HlbAJrR 82bw== X-Gm-Message-State: AOJu0YwY3NVg/BKFl02LBIHOy923XVK6+aCd2xAy9Q8WEwf98WMyd4pz mEO+cfjuIij7ycxzFavwmSk= X-Google-Smtp-Source: AGHT+IF5S3YSuVJuMnIroBfzlKEArQwK6oA8IcmOqMTEPCcluiTC466vv9ldoH0VuyHRPsFdIiAe+Q== X-Received: by 2002:a05:6214:21ea:b0:63d:753:fc4 with SMTP id p10-20020a05621421ea00b0063d07530fc4mr5494988qvj.4.1693362483004; Tue, 29 Aug 2023 19:28:03 -0700 (PDT) Received: from hurd (dsl-10-132-204.b2b2c.ca. [72.10.132.204]) by smtp.gmail.com with ESMTPSA id z15-20020ae9c10f000000b00767177a5bebsm3458217qki.56.2023.08.29.19.28.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Aug 2023 19:28:02 -0700 (PDT) From: Maxim Cournoyer References: <295ef8c8-574a-4169-98f3-6d9aaeb773f1@telenet.be> <6a62aced-9138-0496-fb01-d5d8e89ba8d6@telenet.be> <87h6ohc3gk.fsf@gmail.com> Date: Tue, 29 Aug 2023 22:28:01 -0400 In-Reply-To: (Maxime Devos's message of "Wed, 30 Aug 2023 00:44:08 +0200") Message-ID: <87zg296z7y.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) 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: 2.78 X-Spam-Score: 2.78 X-Migadu-Queue-Id: 88D0E55662 X-Migadu-Scanner: mx2.migadu.com X-TUID: K71VbG7W9pQ9 Hi Maxime, Maxime Devos writes: >>> The first part looks reasonable to me (though I would decrease 7 days >>> to daily or even hourly, as I don't see a point in the delay), but how >>> does the second part (removing packages) make sense at all? >>> I mean, if you do that: >>> 1. Build failures happen (independent of whether you do that). >>> 2. Hence, by doing that, the distro shrinks over time. >>> 3. Leading to frustrated users(*), because the packages they were >>> using and which were working well were suddenly removed for no good >>> reason (**). >>> 4. Leading to less people fixing build failures (because of the >>> frustration). > >> We could bump the expiry time to 180 days, or even 365 days (a full >> year). If nobody opens an issue for a broken package in that amount of >> time, it's probably not used much if at all and may not be worth the >> maintenance burden. > > Please read the subject line of the original message, subject lines > aren't just fluff. Believe it or not, I actually did! :-) I was replying to the first part of your message, where you mentioned you were against packages removal. My reply was giving support to devising policy that would define when it's acceptable to prune the distribution of broken/unmaintained packages, which is tangentially related to the topic of reporting broken packages. These are just ideas and if we decide to turn some of them into policy we could write it in a way that would favor resolving problems instead of just making them disappear. [...] > If maintainers check that no new build failures are created, then over > time the total amount of old build failures becomes roughly zero > (roughly, because of occasional mistake and new timebombs). You mean that the building vs failing ratio improves, right? I'm all for giving a best effort to keep as many packages as we have the capacity to do, but at some point the Pareto principle kicks in and you realize there's not that much value in spending 3 days trying to fix a hardly maintained leaf package that has been failing to build for a year or two. [...] > (*) Sometimes upstream is really not with the times instead of > slightly out of touch, sometimes the broken package has a good > replacement and often security updates need to be performed before > they existed, but the =E2=80=98remove packages=E2=80=99 proposal is not l= imited to > such exceptions. This is the kind of considerations that we could mention in a package removal policy (basically mention it's a last resort thing). >>> [some other part] >>> Expanding upon this a bit more: >>> * Expecting that people fix build failures of X when updating X >>> seems >>> reasonable to me, and I think this is not in dispute. >>> * Expecting that people using X fix build failures of X or risk >>> the >>> package X being deleted when someone else changed a dependency Y of >>> X seems unreasonable to me. More generally, I am categorically >>> opposed to: >>> =E2=80=98If you change something and it breaks something else, you >>> should >>> leave fixing the something else to someone (unless you want to >>> fix it yourself).=E2=80=99 >>> (I can think of some situations where this is a good thing, >>> but not >>> in general and in particular not in this Guix situation.) >>> I mean, I don't know about you, but for me it fails the >>> categorical >>> imperative and the so-called Golden Rule. >> >> I think we can all assume contributors are acting in good faith and >> are ready to fix any problems resulting from their installed changes; >> but they need to be made aware of these failures. [...] > > Again, how does this reply addresses what you quoted? Like, this is > a valuable reply (and I mostly agree with it, but I would qualify > =E2=80=98contributors=E2=80=99 as =E2=80=98most regular contributors=E2= =80=99 (**)) ... but it is not > a good reply to what you quoted. > > * if you left out the quote or separated your reply from the quote > (more explicitly, you could e.g. start with =E2=80=98On related matte= rs, > ...=E2=80=99), it would be fine. > > * but if you don't, then you're blatantly ignoring what I wrote, which > is not fine at all. The text of yours I quoted was to provide some context as to what I was answering to; I replied to the essence of your argument I synthesized from it, not point by point as I agreed with it and it wouldn't have added much to do so. > It's something I have encountered and pointed out (less explicitly) in > the past in other threads as well. I think it's a common reaction when faced with a detailed text -- some people may simply ignore it, feeling overwhelmed, or they may synthesize the essence of it to keep it high level and the discussion more fluid. I don't think it should be perceived as mean; a partial reply is still better than none. --=20 Thanks, Maxim