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 kORRKlDH2ma6EAEAqHPOHw:P1 (envelope-from ) for ; Fri, 06 Sep 2024 09:11:44 +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 kORRKlDH2ma6EAEAqHPOHw (envelope-from ) for ; Fri, 06 Sep 2024 11:11:44 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=JUDbnAFV; dmarc=pass (policy=none) header.from=gnu.org; 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=1725613904; 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=ks7Sck4DKhDy+FGJ8W3t62tsQXobpND+22DGTP+ymvY=; b=kXUKjxFvaaZOLlh1D0GWsE1+7jJbEhRGMStZmKPTXNVKXJ1mN/Fx7vSZ4BuReewT/Go/LO S5xOxGYdQDQlL5W1CBkij+gAeXQIj+hbXVHHMcvopPjyNX0DOEyKFz4YbXqFnDvulSrrZV hMYwcACI02M98kXcF9IbCb31wvJxLsMacQbaKa79WWqTzEdvAjHFIeyeNgS5j4VYe6Mzlj qOAiHFMMPZPIBqIQQzuMMQNIuZyAI6ipzoqlNTOApNJ1YJ/jDC2YBrUHm5B1mts9cMngWc YsN74Df4WCfsn1ZIM3zMq24FLYjhcyxoZ1HDwbVv87vlZzAIxhzimLGMlUEokQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725613904; a=rsa-sha256; cv=none; b=gaac/KOXoxSXMcC4i4OR57yx4HNQNbSg8Vfr5DzbN2WSgmEojRCw+eiPijZlCi2/TPSH8c jHEWprAhC/dnGxmj3uMJXzwhDNrp+RGQDZh8yN5tZ2YIXJ8VGty5EQ4wqh0LeQn6aRz1vC B+0kVmQNaYDyWbxqhJb+4P0xChgqIIKVwRWYefYIcwzSrVwcBaHScEJG7pmgJexKR7lZNH Y7JRjlr/l9d0YZdoO9As8lLP1YaYR9eBQuOiDVLsNpQU8lShQWw14gohpa917/hJ6+j5rZ vucLtyJoWAJd925kfG+Mhd0zuMdre6cKOg6W176utWEiyUP4TOBmqaXLzT2xfw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=JUDbnAFV; dmarc=pass (policy=none) header.from=gnu.org; 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 95AF562505 for ; Fri, 6 Sep 2024 11:11:44 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smUzv-0004VT-IJ; Fri, 06 Sep 2024 05:11:19 -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 1smUzu-0004V7-6n for guix-devel@gnu.org; Fri, 06 Sep 2024 05:11:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1smUzt-0002Zb-Tq; Fri, 06 Sep 2024 05:11:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=ks7Sck4DKhDy+FGJ8W3t62tsQXobpND+22DGTP+ymvY=; b=JUDbnAFVsa0Y+o97Kkrk yFVBhhBIGEmws3LV5Ho5+eqVXHAdbnGpjhu6MdRT9kqcPSBO+d6tyQq5pRjWMaukn9Ak64mct3cYz tlM/YJpH2A/kKCKH1NBPJJWcNY+iJwtujH0ikyrwIefuLUFKV9Up7qDWGiAgKDM9qZHbbjvtEgOfZ vObpHSNh1jU3Md2txlOJrI/VaIuRh2VsJwtTbMWJyH1rBH+c3k1VkGn5ew/5t39AReaEimbRySVkU GC/UB6ToAsX3nru2qVbkJEiOfx0ZyhMQVBKmCkcJYFtrSe6qOkB37DuCj2uYmuiIQn3ai227l841y JVJ22cdoRGkouQ==; From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Simon Tournier Cc: guix-devel Subject: Re: =?utf-8?Q?=E2=80=98core-updates=E2=80=99?= is gone; long live =?utf-8?Q?=E2=80=98core-packages-team=E2=80=99!?= In-Reply-To: <87v7zby3r6.fsf@gmail.com> (Simon Tournier's message of "Wed, 04 Sep 2024 14:58:37 +0200") References: <87le0cj13e.fsf@inria.fr> <87v7zby3r6.fsf@gmail.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Primidi 21 Fructidor an 232 de la =?utf-8?Q?R=C3=A9v?= =?utf-8?Q?olution=2C?= jour de =?utf-8?Q?l'=C3=89glantier?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Fri, 06 Sep 2024 11:11:14 +0200 Message-ID: <87zfol170t.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: 95AF562505 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -11.22 X-Spam-Score: -11.22 X-TUID: sYvrtyb5565M Hi, Simon Tournier skribis: > In this picture of =E2=80=9Cmerge train=E2=80=9D, the CI workload and wor= ld rebuilds > will increase, no? > > Consider the two teams: science and this new core-packages. Then > science takes care of openblas (6000+ dependent packages) and > core-packages of grep (6000+ dependent packages). > > When science team wants to merge to master, they ask for a rebuild. > > When core-packages team wants to merge to master, they ask for a > rebuild. > > Therefore, we have two world rebuilds. Or the both teams need to > synchronize and thus the branches are indeed developed independently but > not tested independently. Are they? I don=E2=80=99t have a clear answer to that. 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=E2=80=94e.g., x86_64-only, because (1) we usually have more build pow= er for that architecture, and (2) perhaps we know the problems with those branches are unlikely to be architecture-specific. Then we=E2=80=99d rebase that second branch on top of the first one, and bu= ild the combination for all architectures. In the end, we do end up testing the combination of branches, but it=E2=80= =99s more structured than =E2=80=98core-updates=E2=80=99: each team has tested i= ts own thing and we got a better understanding of the impact of each change independently. I also think we shouldn=E2=80=99t be afraid of triggering rebuilds more frequently than now, as long as build farms can keep up. So there are some changes that we=E2=80=99d previously lump together in =E2=80=98core-up= dates=E2=80=99 that I would nowadays suggest having in a dedicated branch, merged independently. In the end, perhaps we=E2=80=99ll have to negotiate on a case-by-case basis. The important thing to me is: independent testing as much as possible, and well-defined responsibilities and scope for the people/teams engaging in such changes. Ludo=E2=80=99.