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 GHBVOxUB22ahAAAA62LTzQ:P1 (envelope-from ) for ; Fri, 06 Sep 2024 13:18:14 +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 GHBVOxUB22ahAAAA62LTzQ (envelope-from ) for ; Fri, 06 Sep 2024 15:18:14 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=f2ICMHka; 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"; dmarc=pass (policy=none) header.from=libre.brussels ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1725628693; 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=/EN+josx+fsJHgFL7NON8QVLdnkd2RNf35z0fWOO86M=; b=p/4zIh9L5pTYkT9RW6nj4iHNraEqPFExQh8QnS8G+9FMHVd0n6D5dPMFh9op1MoY4sItsc 5QSg4/hnKD1CvDrVpm6hnyowfiJOvRF83BHaAqk6y5p6XHNkhdEmTqxJPNb4UoXsAHD3uL rno83RBtprwt2E7y7BjP7NCtVmNlNhj5p/q/VDCup7c+jMUIlr42c3k070A6QxtQbz5HBl RCTjA+MT3g9GjvHMUnmIOPMwQoxGaumosVTD5Pb/wOyt/6V91TH5mky8uZGOYv0iTKjf2r HiLGNejAgGlv4atEotyZTQXURows9DK4A+8N+L30h6wTMLbSEgPw7OG+2FebrA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=libre.brussels header.s=mail header.b=f2ICMHka; 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"; dmarc=pass (policy=none) header.from=libre.brussels ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725628693; a=rsa-sha256; cv=none; b=KItLw8RhuH8CHJP/V5qNmgCMiwMEsrgVZ0QPrIeB1ZJbX5cnje8/xMkuzA2D2pOiSBN2L0 W/RyYhlfwnNIZ/Itn2zd1PD3WWzfhCH406Za9A2diUSn3l6Dh2VLmZr6OfKN4e26kk9ZB6 /odvquyQOARhwB8CcIx85JI5cJnX1l1anpx4HXQ8VcZiohJCidtxoDL90UKycYVBmgkl7o tkUIM+Yvv4H2HYajQ7+beXKGDEp0eb3Yh0Rin8Jid2VHStKY2kgy8f9gtIngX6C44iIfuJ 1qsO4aW4eZ9I2OAh3a7m8xgGfB+U12wKx0YsmprnYzm2jqkx1QKnxeNQlHxPiw== 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 740A76474E for ; Fri, 06 Sep 2024 15:18:13 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smYqS-0007r0-6X; Fri, 06 Sep 2024 09:17:48 -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 1smYqP-0007i9-Jl for guix-devel@gnu.org; Fri, 06 Sep 2024 09:17:45 -0400 Received: from libre.brussels ([2a01:4f8:201:1044::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1smYqN-0007Gk-8S; Fri, 06 Sep 2024 09:17:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libre.brussels; s=mail; t=1725628659; h=from:from: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; bh=/EN+josx+fsJHgFL7NON8QVLdnkd2RNf35z0fWOO86M=; b=f2ICMHka+uje5/6BIqpRqmq/PL3Gfmj2FpHC2n+QqrCk8ghAKFjZjmDLGvlbjzihiN8sBt rRNnMoYBjDSJKP1+S3CSMiksnxLugOI2X2ujJBofTvKKtqEEa00HOBWVT2eaTqB+F+Adv/ FuvHWf1wshd9dnC0WDbNm7PIR4NtMKA= MIME-Version: 1.0 Date: Fri, 06 Sep 2024 13:17:39 +0000 From: indieterminacy To: Andreas Enge Cc: =?UTF-8?Q?Ludovic_Court=C3=A8s?= , Simon Tournier , guix-devel Subject: =?UTF-8?Q?Re=3A_=E2=80=98core-updates=E2=80=99_is_gone=3B_long_l?= =?UTF-8?Q?ive_=E2=80=98core-packages-team=E2=80=99!?= In-Reply-To: References: <87le0cj13e.fsf@inria.fr> <87v7zby3r6.fsf@gmail.com> <87zfol170t.fsf@gnu.org> Message-ID: <01f3e72b16d6719aed3596956f16f22a@libre.brussels> X-Sender: indieterminacy@libre.brussels Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a01:4f8:201:1044::1; envelope-from=indieterminacy@libre.brussels; helo=libre.brussels 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -6.19 X-Migadu-Queue-Id: 740A76474E X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -6.19 X-TUID: pQQbyef1m66V On 2024-09-06 10:09, Andreas Enge wrote: > Hello, > > Am Fri, Sep 06, 2024 at 11:11:14AM +0200 schrieb Ludovic Courtès: >> The way I see it, one of the branches would be tested independently. >> The second one would also be tested independently, but on a limited >> scope—e.g., x86_64-only, because (1) we usually have more build power >> for that architecture, and (2) perhaps we know the problems with those >> branches are unlikely to be architecture-specific. >> Then we’d rebase that second branch on top of the first one, and build >> the combination for all architectures. > > concurring with Simon, following this description, I also do not > understand > what this concept of merge trains improves as long as it is not > automated > (and we have lots of build power to subsequently build several > combinations > of branches). > > Once the first branch is good, why not simply merge it to master and > then > rebase the second branch on master and test it, instead of postponing > the > merge? After all, building is costly, not merging. > Well, if anybody wants a Friday digression, here is a parable about 'guaranteed connections': https://yewtu.be/watch?v=vHEsKAefAzk YMMV > Notice that with QA, the concept is that the packages will be available > on the build farm once the branch has been built, so postponing a merge > has no advantage. > > Andreas