From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id CCv1No4rYGfmgAAA62LTzQ:P1 (envelope-from ) for ; Mon, 16 Dec 2024 13:30:55 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id CCv1No4rYGfmgAAA62LTzQ (envelope-from ) for ; Mon, 16 Dec 2024 14:30:55 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iazr6dBH; 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=1734355854; a=rsa-sha256; cv=none; b=AxVyo2d6On6pFmySdM97xfunCo7/T4w1oS5Et/ReDweP+80xkMxI6y3GgFPqia6G8Gjysm a5IIW7ghpVQLq0K2FbtXLWqIl47sC7sMwUxn0DR50S+5Vwp1HF7foPrt3qZ1JtnGfTW6ln tzpCry6Li1XLCXtxWaY2WRCeqZyPqc7Ro0CDc1YQUH8Om6fj/CRpfZsYEgfgrdDBUbyjsS l5Hb9KXjgXuoELFXqph0lEPruwuFco3QnoO/aQoCNZu2QiRVapnG0bIFSrcnSNp6qlUost FPXyuLAzs8c3zAqDnXiUMSHHa4BElHOQE1072MJiDSGEBwj3xcwuY6jf9MPHcA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=iazr6dBH; 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734355854; 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:dkim-signature; bh=12PJ06QdgaLomkGWG38nyR2+b/Q35mH30KS1DYg3h/g=; b=p8484JB2Ghhykh03LUGqK2M7cCNiO5KQQmDfypnxfDRxqPnF6t0my0DUGvCZPIpt4xtn/+ j4qWpXX6b9H1pEAzmTktBECvGVkVCzIP6tdhYoExxO3Dwm/eBtu8k1Zb6XJYzxsPGyWdS8 9WHOUWkqIIWlyYqJuBAOkOzrsLLyBIXZxlQGufyZZ+5Y6o6zNDZ4zo27vYFbDLKhiTDm4C jvzepMcTQA28wrJW9SdgDu8t/SeQ/oBSEyT4GJJV2inwSMimRayif7PRjzJbQftKwvOH5n dvNPoF9Y6pI3vX5JBJlnToaDcln/KIkGdP2GpDJ/pS0vyzLQWGmh8rgWq0fiYA== 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 7D5A3A677A for ; Mon, 16 Dec 2024 14:30:54 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNBBC-0004Sg-SO; Mon, 16 Dec 2024 08:30:34 -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 1tNBBB-0004SY-Ai for guix-devel@gnu.org; Mon, 16 Dec 2024 08:30:33 -0500 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tNBB9-0002aq-23; Mon, 16 Dec 2024 08:30:33 -0500 Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-7265c18d79bso4384149b3a.3; Mon, 16 Dec 2024 05:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734355828; x=1734960628; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=12PJ06QdgaLomkGWG38nyR2+b/Q35mH30KS1DYg3h/g=; b=iazr6dBHFq7Ou8H3Dyd7UpdAzoK1GQuZLq4t0ufbzDc79c8CT6hFEtdnGiXDFSGQF1 YR93QGE7Ayf5QrIkkQPTr13P1kwztJonO9sT4DNM47hnbtkRdd/9Re5EaQDIBRTU8ENn wPPpOHoGO4Yj7bQSf0Nn6fcAQrwyaVhnu90w3vXm6W2Hn6oNSV15etgNsqYoOpTxqnog plpqSV5/h9AeTzvn/E8JmvszDRuYG9O3ZAHKxnXxkjLu+5pwidqgKsfogPk1ykj5RFDs M+XYLtqFHzu7V1kigZlzNksaItlfk26lzqL6e4SDIpSxmUaasK0XC0CB1gUPsg1LAp5f pwAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734355828; x=1734960628; h=mime-version:user-agent: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=12PJ06QdgaLomkGWG38nyR2+b/Q35mH30KS1DYg3h/g=; b=lDoMnVIUB76ig9Swz1kmoZfDDGvwZr3w4VZeU/6dh3sXBK3hVA98lJs9Kxqt6BAxcD DM6lI/tgGCgIUuvkz+XMHfsUjafmmE4UTvMcCq+ERXzpUXMHH0dNRSMbiuDlHhye6Caa sRsYKFItsedSEc5qeIqOsUVfBxeO94F91wLmHhGHDOK7eQNrHXpfwjIBcKO67W+ukHYC GrW9PUg3ZHF5IwnLxItVIZOEkA7hllVRzaFLyrk4eUpRtrMRnu+Fyn1uEDDQuLbidwZZ JG4qsenjRXb5a1tXGd5JV6hvF3qFI/5TJWLe6MAVMC8Q0mwzxiiU7a+WmjS0bbl3OlSF n7kA== X-Forwarded-Encrypted: i=1; AJvYcCUzyb60tvX380BU+OMCtZ1GPHs71nDXPhIHjNwHB5RDQQrVVJDjA8Ym2OxLEuDfddfWu7pdGzWzoHzYuAVrXNtlFA==@gnu.org, AJvYcCVR/I8bRsvHEYobbzoEDt5rqKnRNoJScS+RqrlTMwTCSGNxiLU70FxUEtog9jOowIJb6++eaw==@gnu.org, AJvYcCXYwsKdRDbZ/9ZZ2lggiQEmasU3BiHNiBc/kDeYBchQWRFBKBoBzwWXeQfiMAZ1xdsnsuJUYcv+xQYl@gnu.org X-Gm-Message-State: AOJu0YxBllc21inw+VKPV3IjkmvB4ELtZJkp2klT/o1FxQ7pWVeTcngz aNHYJF6iAVtJGy4cdK/VzkoqF2uVUf61QBLgF6KOWNj2SaADJVIjdz6NprNF X-Gm-Gg: ASbGnctLMEGPqA7QiRfpVbxI/ajb9nurElMnjIiqozmsRjwLE3mPrx4hTDaOnBdTTXr U6EwB/NV0JkSQqN5Ela9QPQ/S7OF64I3h0Ae5qdQhI7+QUNCxJotsB9ICu+h7PuwTd8MVOn9pb6 j3U/Lm08weg0Ay9vbbU9kKA97PVqNeerCEggDBlWO+04guWy8O7yZv1/kArxW8a2/TIz2g6bN5z +bfEyCyToJvZwDTDPxgVBxE7wEkSR/GCqF9JsidVg/qj1A3T/PewQ== X-Google-Smtp-Source: AGHT+IEBLyKk0Y5/f5QvBAzeGZZV6LUDyyYllvo6OKlbRHvtlrHmpDZq/ZG2goRvWcTcTE9r4ccIaQ== X-Received: by 2002:a05:6a20:e18a:b0:1e1:9f57:eac1 with SMTP id adf61e73a8af0-1e1dfc19fa5mr17216316637.8.1734355827729; Mon, 16 Dec 2024 05:30:27 -0800 (PST) Received: from terra ([2405:6586:be0:0:c8ff:1707:9b9:af89]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-801d5c3ded0sm4066125a12.83.2024.12.16.05.30.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Dec 2024 05:30:27 -0800 (PST) From: Maxim Cournoyer To: Suhail Singh Cc: Ricardo Wurmus , guix-devel@gnu.org, guix-maintainers@gnu.org, Cayetano Santos , Efraim Flashner , =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: On the quest for a new release model In-Reply-To: (Efraim Flashner's message of "Mon, 16 Dec 2024 11:43:41 +0200") References: <87a5d0dlm8.fsf@inventati.org> <87ttb7rds6.fsf@elephly.net> <87pllskibl.fsf@elephly.net> <87o71c1yuf.fsf@gmail.com> Date: Mon, 16 Dec 2024 22:30:16 +0900 Message-ID: <87bjxbu55j.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=maxim.cournoyer@gmail.com; helo=mail-pf1-x432.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -9.24 X-Spam-Score: -9.24 X-Migadu-Queue-Id: 7D5A3A677A X-Migadu-Scanner: mx10.migadu.com X-TUID: jzkA7G5HDqSp Hi, Efraim Flashner writes: > On Sun, Dec 15, 2024 at 03:21:44PM -0500, Suhail Singh wrote: >> Ricardo Wurmus writes: >> >> > Efraim Flashner writes: >> > >> >> Since, IMO, the major uses of the actual guix package is for the daemon >> >> and the installer, I think we could tag a minor release just about every >> >> time we bump the guix package. >> >> That's a sensible approach. How should the discussion proceed further? >> Do we have a proxy to determine whether everyone who needs to be >> involved for consensus-based decision-making has weighed in? > > I'd argue that cutting releases is one of those specifically maintainer > duties but I'd love to hear from other people who disagree. I'd tend to agree. A maintainer who doesn't cut releases or organize to make them happen is a poor maintainer (hello!). > If we do consider the daemon and installer the main reason to actually > cut a release, then I'd argue the daemon always works (we'd know > otherwise), I think we have an installer team, and we should probably > get some feedback from the desktop teams to make sure everything seems > to be working well enough. > > I have some opinions about our aarch64 based images, but that should be > a separate email. I think one reason I'm so turned off from attempting to produce a release is mainly the very high standard that Ludovic has set for releases (hats off!), which is quite a lot of tedious work: 1. Comb thousands of commits (and since it'd been 2 years, more like tens of thousands of them) to find news worthy items to put in the NEWS.org file (which goes in the eventual announcement email) 2. Write a new blog post for the release, with the above information, and often more detailed explanation on new features. 3. The challenging/labor intensive integration work such of attempting to fix all system tests which often bitrot due to not so many people (myself included) routinely running them and noticing (it's so costly to do so, I can't really fault them), though I/we should register to the CI notifications for the 'tests' job, that'd help keeping track of new failures. 4. Some arcane Perl tool that needs to patch is used to produce the final release email/upload artifacts, IIRC. We should have better tools than that. 5. I remember it to be very time consuming to try to just produce the release artifacts for all platforms, building the current Guix then the nested Guix for all targeted architectures. If it fails, you're in for a new lengthy round as the process must be started over ('make release'). 6. And of course, since a Guix release is mostly useful for people installing it on foreign distributions or as fresh Guix System installations, testing this is important, but also labor intensive manual work. If we can agree that producing a release with lowered expectations is better than producing none, I don't mind to get the ball going. I'd drop the combing of thousands of commits for one thing, focusing just on what's in our etc/news.scm file, or what is on the top of my head. The blog post may be spartan, with little backstory or examples. The email announcement email may not match the GNU release format, until we get to rewrite the tool to match our multi-artifacts requirements (in Scheme, of course). Testing may have been mostly left to testers out there that have foreign systems or VMs to experiment with, or the time to install Guix from scratch using the installer. A best effort would be done to fix as many tests before releasing, without the promise of fixing them all. Parties interested in refining the release process can have a look at the 'release' target of our Makefile.am file at the root of the Guix repo, or at the doc/release.org file in the guix-maintenance repo. Long term I think I'd like to see for releases: 1. Simplicity - just a tag, release email, artififact uploads may be good enough, if we release often. 2. Automation - We already have many things automated, but it could be polished a bit more (such as a better tool to produce the announcement email), and perhaps some way to automatically test that a Guix istalled via guix-install.sh' in various environments work (perhaps Docker could help with that, having readily minimal images of Debian, Ubuntu, Fedora, etc. to run our script on). 3. Frequency - we want to release often -- Thanks, Maxim