From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id yA88MsuX1GbafQEAqHPOHw:P1 (envelope-from ) for ; Sun, 01 Sep 2024 16:35:24 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id yA88MsuX1GbafQEAqHPOHw (envelope-from ) for ; Sun, 01 Sep 2024 18:35:23 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=futurile.net header.s=selector1 header.b=MSKYzqd5; dmarc=none; 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=1725208523; 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=Xlzj5lOOqhD9GM1iobwJKuYlb7TDEquA8CVIei+zcpk=; b=qre7WQoVDV78la2vpK9f2xiNc4ikdR9gpHe1VRIOxDqvS/X4uVkkQs8EnyKMTvSZmHfGpN Jo1YOlzLXN9+kgnL81mP29xTNEoheZBL95SplLRqbctdeUlFzxjKFktOQKUplt0Ecavisq wUUCJs+bZMM1kEVd2wJseJM0oFeGNuylCkrh1NWHnzGwcMKUHct5oK+RVuh8nlz8Mj9/7J dOVUR6FMqa3MBdOBPa4Y7nyCMdwCk7GfW3b9czIjiq2/+vtgzGmIKhyfTRRveIeSBzUeN4 lgSOnW69jNcFQNkqiMsAf/wRUZ/JH8zfuV+hAYVHAfC2Hy55uTlo69jvE80Apw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725208523; a=rsa-sha256; cv=none; b=OA3lngJJOAnVXm4J0gIcPK1GAbVb8GltVBbuitiFWcslXCuYSP6uhmHDKlWSDWTtP2vwGA TKin1o+qIi6P2hzDqqucTptQ95yP6j5jYlS9IObmjHr0TBIlG7/rYxbFQC7GI0jlCOijVY pNi/P3707HKHP6OIQgi6al7tflBZuMYscrlxdQpSyfHcACt+6v/9t6gY1XYnZ81NvZ33Cp HBpUAnBVS0th/Df/nB09NujVYBy6ta5aY3a4yUya9DVD9K5FT0K8uvolk310EDyx3lDxyN 35yLhR2vcmj4DOzITC/ylgz5eKnST4TT9AxO89VSeb+27XO8SnqiZ6Hjlz2ZiQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=futurile.net header.s=selector1 header.b=MSKYzqd5; dmarc=none; 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" 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 62F7B61841 for ; Sun, 1 Sep 2024 18:35:23 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sknXJ-0004mi-Cm; Sun, 01 Sep 2024 12:34:45 -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 1sknXF-0004mQ-IX for guix-devel@gnu.org; Sun, 01 Sep 2024 12:34:42 -0400 Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sknX6-00081m-Ic; Sun, 01 Sep 2024 12:34:37 -0400 Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1sknX0-00B8Jj-9P; Sun, 01 Sep 2024 18:34:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=futurile.net; s=selector1; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Xlzj5lOOqhD9GM1iobwJKuYlb7TDEquA8CVIei+zcpk=; b=MSKYzqd5ZajxiWa2ce/joMqpON uFCvdGNHccIwHPoGOVTvdvDTAg4TgahFbMRj4BZZCi7FqQNK1K1+OZP0Gvtko+ElZgeyNkiDUr8yH mbpl51oDpgQyp1NWldJZg5oTemzSlswhsgTX/ej7C/WRM6HOzFKeAciHmCP5mpKk6ZbiPoiyUYv2c 5vxx258GNzrbVrdLY3bHT34ckq+GtnWfnJAcCQI9ibINLD0nBlyz50cP/JxO5E8WdXpQFNq+MowSK mR4fNHf8zjUVhbnAvmes9pEWpRwvsyhe4InoYKzry7R/ymb1T1DWTwY43bKtpuHlpovBSh1DBR92i XIn2dZ+A==; Received: from [10.9.9.74] (helo=submission03.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1sknWz-0000uP-Mb; Sun, 01 Sep 2024 18:34:25 +0200 Received: by submission03.runbox with esmtpsa [Authenticated ID (641962)] (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93) id 1sknWo-00GoW0-4C; Sun, 01 Sep 2024 18:34:14 +0200 Date: Sun, 1 Sep 2024 17:34:13 +0100 From: Steve George To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel Subject: Re: =?utf-8?Q?=E2=80=98core-updates=E2=80=99_is_gone=3B_long_live?= =?utf-8?B?IOKAmGNvcmUtcGFja2FnZXMtdGVhbeKAmSE=?= Message-ID: References: <87le0cj13e.fsf@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87le0cj13e.fsf@inria.fr> Received-SPF: permerror client-ip=2a0c:5a00:149::26; envelope-from=steve@futurile.net; helo=mailtransmit05.runbox.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, T_SPF_PERMERROR=0.01 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 X-Migadu-Queue-Id: 62F7B61841 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -8.91 X-Spam-Score: -8.91 X-TUID: GSXO4isWqJCo Hi, I have a question on one part of the workflow, and would like to propose an addition to the 'stateless' branches Chris suggested: On 31 Aug, Ludovic Courtès wrote: > Hi again! > > Over the years, consensus emerged that ‘core-updates’, as a branch where > we lump together all sorts of rebuild-the-world changes, is no longer > sustainable. Those of us who were at the Guix Days in February 2023 > came to the conclusion that (correct me if I’m wrong) we should keep > branches focused, with a specific team responsible for taking care of > each branch and getting it merged. > > There’s now a ‘core-packages’ team, so there will be soon a > ‘core-packages-team’ branch focusing exclusively on what’s in its scope, > as specified in ‘etc/teams.scm’. There’s already a lot of work to do > actually: upgrading glibc (again!), coreutils, grep, etc., and switching > to a newer GCC as the default compiler. That branch won’t be special; > it will follow the conventions that were adopted last year: > > https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html > (...) > To reduce world rebuilds, perhaps we’ll sometimes create “merge trains”, > whereby we’ll merge, say, the branch upgrading CMake and that ungrafting > ibus on top of ‘core-packages-team’, and then merge this combination in > ‘master’. The key being: these branches will have been developed and > tested independently of one another by dedicated teams, and the merge > train will be a mere formality. Under the 'patches and branches' workflow, what should happen to packages that are *not* part of any team, but do cause a rebuild of more than 300 dependent packages? Andy Tai gave an example of ffmpeg [0]. There aren't enough contributors or committers for every package to be covered by a team, so this seems like a permanent constraint even if more teams do grow over time. The manual currently says it goes to 'staging' [1], and that this will be merged within six weeks. Is this actually true? I don't see any sign of it on Guix' git [2], and an unsure if the manual is out of sync with the branches workflow. While 'staging' seems like it could have similar difficulties to core-updates if it gets out of hand. The alternative choice of each time someone making a branch 'ffmpeg-and-stuff-i-collected-with-over-300-rebuilds' doesn't seem like a better choice ;-) > Recently, Christopher Baines further suggested that, as much as > possible, branches should be “stateless” in the sense that their changes > can be rebased anytime on top of ‘master’. This is what we’ve been > doing for the past couple of months with ‘core-updates’; that sometimes > made it hard to follow IMO, because there were too many changes, but for > more focused branches, that should work well. (...) Long-lived branches and ones that don't cleanly apply onto master cause lots of difficulties from what I've seen. Perhaps a lesson is that branches should both be stateless *and* should not exist for more than 3 months. We already have a rule that encourages atomic changes within any patch in order to make things faster/easier to review. By extension, lets do the same with branches - merge them more often. I would propose a patch to the managing patches/branches sections of the manual depending on what the consensus is here. Steve / Futurile [0] https://lists.gnu.org/archive/html/guix-devel/2024-08/msg00202.html [1] https://guix.gnu.org/devel/manual/en/guix.html#Submitting-Patches [2] https://git.savannah.gnu.org/cgit/guix.git/refs/heads