From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id EMdmMBzvUWDLagAA0tVLHw (envelope-from ) for ; Wed, 17 Mar 2021 11:59:24 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 0HpHLBzvUWD9KQAAB5/wlQ (envelope-from ) for ; Wed, 17 Mar 2021 11:59:24 +0000 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 2008DDCEC for ; Wed, 17 Mar 2021 12:59:24 +0100 (CET) Received: from localhost ([::1]:56772 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMUpf-0002Ds-8L for larch@yhetil.org; Wed, 17 Mar 2021 07:59:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53266) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMUpU-0002Dk-Qm for guix-devel@gnu.org; Wed, 17 Mar 2021 07:59:12 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:43865) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lMUpP-0005dL-GG for guix-devel@gnu.org; Wed, 17 Mar 2021 07:59:12 -0400 Received: by mail-wm1-x32a.google.com with SMTP id u5-20020a7bcb050000b029010e9316b9d5so1134401wmj.2 for ; Wed, 17 Mar 2021 04:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=M+N1XuSb5u8QIdqUGcb7nI38Ep78nzqt/270+3txWYE=; b=qpopKfBhwURiznKaeIe2jFY6TnZRVFL17uUqHNveZ+p2rhn2soL5BJCLeULvT4sQJY td0Pqn7iUtrNDjxi8TVE+LUKEmTWtzBtB85Jf8Pge3xm6yN7ok9F5ggczulaZrz0REzd 6h9VBtM17oYeYkQsFH53eJJNNZ6SuiOd78WA3YSw8VtYHpsYHLlAQKV+VW7Ix7e2wsC2 WI6IxxZ4a1Y+S9j+fcYAqXteJ9h73YyICWTfIjqclprWIpsJj/D21O5l8hLkciQYsrn7 dwpp3Bgv1cz/aSVomVGTwtnO9DtVZwzk12EF5T/8mkxOvsbQQZ2i7TEVnNrH6H/EvN10 D85A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=M+N1XuSb5u8QIdqUGcb7nI38Ep78nzqt/270+3txWYE=; b=NoS6+AB53hMiXatgGY17eQ28C/MDsEUtp9mMgWCYnFdVvwxJkcN4z6ByqNLN9wLTS/ j/ewIPcnezuzfw55eGRLzf0en+X/pVi5YDH1fX10BFmlDpfTMN6oOWkfaPf9gAgcmAcZ EUENkfgubX4K36tvr0w3rk118zm7H+/X/cDcJKJBD5dy0vxlSNFqrof52b8d6fkpNldI VeY7kJOUL3ujCdJUkpJdXA96wJtLdVZ7gcK61CjC6hp/O/nQffRvIDrOWiboPEEWnMFe cYoTGbg2HLL2UPucEjKQNMyNEDQRSSW7mTTJP6h+HC/ggnnPayvl7mxcIBXlEyfXjKfP SIXg== X-Gm-Message-State: AOAM532e4DojRSXxL8DqHKxmuvpnuRWPIB1h/lXw/MWCRC4CuXGpsg3z GCQlZ1gu48iSQn5nRJMQmqkZpnJmpWQ= X-Google-Smtp-Source: ABdhPJyekf8TE5cnCarnY7ERZnW/dBzBNybbmeb2Cg24cRWq3LkQlrnyjtVFsllCOB4aWlCy3QlkIw== X-Received: by 2002:a05:600c:c4:: with SMTP id u4mr3379891wmm.27.1615982345776; Wed, 17 Mar 2021 04:59:05 -0700 (PDT) Received: from lili ([2a01:e0a:59b:9120:65d2:2476:f637:db1e]) by smtp.gmail.com with ESMTPSA id a6sm2733820wmm.0.2021.03.17.04.59.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Mar 2021 04:59:05 -0700 (PDT) From: zimoun To: Leo Famulari , Mark H Weaver Subject: Guix moving too fast? In-Reply-To: References: <9b9a43a584e2dc70488482fce5931b46abd0e006.camel@zaclys.net> <87v99qit39.fsf@netris.org> Date: Wed, 17 Mar 2021 12:54:39 +0100 Message-ID: <86mtv29erk.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::32a; envelope-from=zimon.toutoune@gmail.com; helo=mail-wm1-x32a.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.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1615982364; 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=M+N1XuSb5u8QIdqUGcb7nI38Ep78nzqt/270+3txWYE=; b=HmKKammtSq/VOtlNBO56pnKNGgxu3Lxe6lwGwDUIyqZzyYBxvTWLFL1ItwSCmr9eW6dQG5 2KG0itnZm54uPW4n/UuSTwao2igJahMRJv0zP0bhXDO/IDBDcMlWHsuF3atHX5vIKdczRz KiMv88Zex2X3gLjHZ9kGe5hOcjhRMLRyeJEW4IE1dCVT4BCDiEgA6f8Jd/E21IQwh3oo7+ lfJQZKsSat89aXg2soHaHT13OjHhbL6dELs+teV7GTR9FAH/1gLbqEReSJZlFbCKFN/LZS kxSWS38DAC6yGSJyGxCxjZm+ZeJ3Qqqyw4/gdCe6KVnTKzOyc8rh4ZZ/XqJFww== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1615982364; a=rsa-sha256; cv=none; b=d788koZ04+fmAyInuCPMOiTNQ6GUYmke7lNKp7Cbls4ou9plvkyEjQbdIhjcH17LxFBXdt /XxIjWFjmq3FUxsp8zf6wnIrWkjfRvUuQPgwzgTX6HXrCBpb2pac9giu0gmy44uqAXsCPP p4k9lbapNeAobLc8T7Dcpx2mg3NrYAwu9S+WKZQ9GkPxKddUDzo0GFTBv/R+LEpRTKzhci vimNjB1oCncUuvJGf+9YhSV9EMzs3yJC5G01X1cjqBZ1lWTWomkDnEaHYgjakDu5WrPF/6 IEMrT6/PiisyT3ad6mInEO1tsBRUhCJTOGzg7zJi6GwMbn7l7zCqGBIcFCosXw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=qpopKfBh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -2.10 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=qpopKfBh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 2008DDCEC X-Spam-Score: -2.10 X-Migadu-Scanner: scn0.migadu.com X-TUID: AtHa8PwCvdb3 Hi, Thanks Mark for your words. Interestingly, using the angle of scientific software, I agree with your general analysis. On Tue, 16 Mar 2021 at 19:49, Leo Famulari wrote: > On Tue, Mar 16, 2021 at 07:19:59PM -0400, Mark H Weaver wrote: >> Ultimately, I gave up. In my opinion, Guix has never achieved usability >> as a desktop system on non-Intel systems. Therefore, the Guix community >> is unable to attract many developers who want a distro that supports >> non-Intel systems well. Our community has thus become dominated by >> Intel users, and there's unsufficient political will to adopt policies >> that would enable us to provide a usable system for non-Intel users. >>=20 >> What do you think? > > Thanks, as always, for your well-reasoned message. Your story of your > experience here, and what it means for Guix, computing security, and > free software in general, is really valuable. I still think it's really > unfortunate for the rest of us that you gave up, but I don't see how it > could have gone differently. Moving less fast? :-) > I agree with you that Guix moves too fast to support non-Intel > architectures in its current state. My hope is that, within the next two > years, there will be workstation aarch64 machines more widely available > at comparable prices to Intel/AMD, and this will translate into more > developer support for aarch64 in the years after that. Time will tell. Moving too fast, i.e., pushing a lot of changes, has various other consequences: a lot of rebuilds, even if the build farm is really improving these days, there is a high probability that =E2=80=9Cguix pull= =E2=80=9D intensively computes=E2=80=93=E2=80=93hopefully =E2=80=99channel-with-subst= itutes-available=E2=80=99 [1] avoids that for limited resource machines=E2=80=93=E2=80=93then =E2=80=9Cgu= ix install=E2=80=9D right after generally builds the package locally. For example, the package =E2=80=99gmsh=E2=80=99 [2], there is no substitute for 373c7b5 (pulled on M= arch 13th couple of days ago) but builds fine, and this =E2=80=99gmsh=E2=80=99 packag= es had been last updated on Oct 8th 2020. If you look at the Data Service [2], there is 7 different =E2=80=9Cversions= =E2=80=9D for the same 4.6.0. Therefore, it had been implied by some unrelated changes. That=E2=80=99s fine and that=E2=80=99s why Guix is so great: 4.6.= 0 is not enough for the binary versioning. This can be really worse, for instance the package =E2=80=99openfoam=E2=80= =99 [3]. It is a complex package and for the same 4.1, the output version changes every 5 days on average. How is it possible that the build farm follows such rate? Another example, the package =E2=80=99freecad=E2=80=99 [4]. Even worse, what happens if an unrelated change breaks the package? The time spent at fixing it is not spent at adding other nice-to-have packages or fixing bugs. Or we prefer to add/update other packages or add features and this case, because we do not care, this broken package should be removed: from a user perspective, nothing is worse that broken packages and from the build farm perspective, it saves resources. Currently, there is ~5% (~1000 packages) of broken packages. My guess is, considering the same rate of changes and an increase of the number of packages, this percentage would be the same, i.e., the number of broken packages would be higher. Well, because scientific software are often complex, meaning with a huge dependency graph, it makes hard to maintain them with such change rate. And I am not speaking about third-party channels. They are also hard to maintain. To that, let multiply by the number of architectures. All in all, maybe the 3 branches model does not scale well. It should not be possible that broken packages are in the default branch (now master). It is unavoidable with the current model. Chris initiated discussions and works about QA with patchwork, see [5,6]. Somehow, what is =E2=80=9Cproduction=E2=80=9D should be distinguished from what is =E2=80= =9Ctest=E2=80=9D. It is not currently the case, every updates is pushed to master and we cross the fingers=E2=80=94=E2=80=93it works well most of the time though, the rare br= oken cases are just full annoyance and too visible to my taste. The default branch could be =E2=80=9Cstable=E2=80=9D, which receives only s= ecurity fixes, i.e., grafts, also bug fixes and patches touching =E2=80=99guix/=E2= =80=99. All other patches, i.e., touching =E2=80=99gnu/=E2=80=99, could go to =E2=80=9C= next=E2=80=9D. And massive rebuilds could go to =E2=80=9Cmassive=E2=80=9D. Each time a graft is added= , it is also ungrafted to =E2=80=9Cnext=E2=80=9D (or =E2=80=9Cmassive=E2=80=9D if it is = a real deep change), therefore, each release becomes (almost) ungrafted. The branches =E2=80=9Cstable=E2=80=9D and =E2=80=9Cnext=E2=80=9D are contin= uously built whereas =E2=80=9Cmassive=E2=80=9D only built before the merge. Every 3 months, =E2=80=9Cnext=E2=80=9D is merged to =E2=80=9Cstable=E2=80= =9D. Every 3 months, =E2=80=9Cmassive=E2=80=9D is merged to =E2=80=9Cnext=E2=80= =9D. Every 6 months, =E2=80=9Cstable=E2=80=9D is released. Like a metronome. For instance, if the =E2=80=9Cmassive=E2=80=9D merge is = missed for whatever reason, it is delayed to 3 months but =E2=80=9Cnext=E2=80=9D is st= ill merged on time and the release is on time too. I do not have a clear view about other architectures than x86_64, but since =E2=80=9Cstable=E2=80=9D is moving slower, it could be discussed at t= he =E2=80=9Cnext=E2=80=9D merge time some changes specific to these other architectures, i.e., exclude changes because they are failing or accept it fails for these architectures. And =E2=80=9Cstable=E2=80=9D never receives changes that breaks packages (a= t least for x86_64), it lets us couple of weeks to fix or revert offending commits. Substitutes are always there for =E2=80=9Cstable=E2=80=9D. The rolling rel= ease becomes =E2=80=9Cnext=E2=80=9D and not =E2=80=9Cstable=E2=80=9D. Wait, wait, it looks like =E2=80=9Cmaster=E2=80=9D, =E2=80=9Cstaging=E2=80= =9D and =E2=80=9Ccore-updates=E2=80=9D. ;-) It just changes where to push. And such model needs time to transition if we agree. We could start after the next release 1.2.1 and we could expect a smooth schedule as described 2 or 3 releases later, I guess. Cheers, simon 1: 2: 3: 4: 5: 6: