From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id QCp+A02f1GYwPAAAe85BDQ:P1 (envelope-from ) for ; Sun, 01 Sep 2024 17:07:25 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id QCp+A02f1GYwPAAAe85BDQ (envelope-from ) for ; Sun, 01 Sep 2024 19:07:25 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1725210445; 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; bh=thynkyl63BHOwtI0Isp6b6h2OzFw6o2Sp0tHSiy4kyk=; b=HMpqCyTLTffcf0H5vxXzwfJ2bUHzEFKMTWfhr1dIncM42Rh3BQNucIUF3TMhnIPZEpG6re qhBW1MxS1KMeNur0fNrNt4HbVI9OwiRMQpOYd/+JX3yi9U32WvpiHuWArXE3QS/miI8jfz Av8Z8LlDAhcd8iGzDV27PG/ez3Y1+4wKsmDDmE44LkN20GYE6wJlvQpn1gouWG38xnGiMi +rxXHUyATg3xWyZQEg11cj+4Xb9ajc0PXAkyk6Nrth3rkqnpY24P7W2bEvh0SUSDCJB4W5 j4/9lI8rjFpdnFgYn6MIwRnjWdeqZg9g124fYVTZV91SkxLrdio2gkP8H1X3EA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1725210445; a=rsa-sha256; cv=none; b=EbB09uAORl7zxl0GsM3iP3v9PUfNI7U/tQ9tGGSENKZCIRdcabsp/A9BCVhS52svCWnAag DWZ5SnK3lyUQsQ1hMb8Y/+Z8aeQ2OumDaXRB6lAnaTnPp965I/VvTbKPXMT7WeOTkkTQwr QnQrxsuHV2QpJ/rXudfB5zt7hFJRJmftfyb/ZrxwUOSydWHFTVAYwkT1ThzSXWNTs6reXV cTjwXmMNwwlPcW7tlCalOHZOQY2/VJVFEBWtQItrBwfG7fTKHtYfAnI98OEolepfzHvueJ LFdH5QUWxDFkj+cr3iFHKjZK0dfcSPPxFQbfpQbp8OuVcDM5DfzDpxhAv2fIrQ== 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 BF8E21636E for ; Sun, 1 Sep 2024 19:07:24 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sko2P-0001aY-2m; Sun, 01 Sep 2024 13:06:53 -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 1sko2K-0001aL-Nr for guix-devel@gnu.org; Sun, 01 Sep 2024 13:06:49 -0400 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sko2H-00050p-OH; Sun, 01 Sep 2024 13:06:48 -0400 Received: from localhost (unknown [212.132.255.81]) by mira.cbaines.net (Postfix) with ESMTPSA id 2B6A327BBE2; Sun, 1 Sep 2024 18:06:42 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id d5f88377; Sun, 1 Sep 2024 17:06:40 +0000 (UTC) From: Christopher Baines To: Steve George Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , 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: (Steve George's message of "Sun, 1 Sep 2024 17:34:13 +0100") References: <87le0cj13e.fsf@inria.fr> Date: Sun, 01 Sep 2024 18:06:38 +0100 Message-ID: <87v7zfuwv5.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=212.71.252.8; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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-Migadu-Queue-Id: BF8E21636E X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -8.58 X-Spam-Score: -8.58 X-TUID: UGPA5q4Ltv/e --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Steve George writes: > On 31 Aug, Ludovic Court=C3=A8s wrote: >> Hi again! >>=20 >> Over the years, consensus emerged that =E2=80=98core-updates=E2=80=99, a= s 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=E2=80=99m wrong) we should = keep >> branches focused, with a specific team responsible for taking care of >> each branch and getting it merged. >>=20 >> There=E2=80=99s now a =E2=80=98core-packages=E2=80=99 team, so there wil= l be soon a >> =E2=80=98core-packages-team=E2=80=99 branch focusing exclusively on what= =E2=80=99s in its scope, >> as specified in =E2=80=98etc/teams.scm=E2=80=99. There=E2=80=99s alread= y 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=E2=80=99t be sp= ecial; >> it will follow the conventions that were adopted last year: >>=20 >> https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Br= anches.html >>=20 > (...) >> To reduce world rebuilds, perhaps we=E2=80=99ll sometimes create =E2=80= =9Cmerge trains=E2=80=9D, >> whereby we=E2=80=99ll merge, say, the branch upgrading CMake and that un= grafting >> ibus on top of =E2=80=98core-packages-team=E2=80=99, and then merge this= combination in >> =E2=80=98master=E2=80=99. 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 "Managing Patches and Branches" section deliberately doesn't mention anything about teams as there's no requirement for branches to be associated with teams. Grouping related changes together is good for a few reasons, but it's absolutely fine to have a branch which updates a single package, not related to any team. As noted on the page as well, if you don't have commit access (which is required for creating branches), you should just open the issue then hopefully someone with access will create the branch for you. > 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 ;-) That page needs updating I think. >> Recently, Christopher Baines further suggested that, as much as >> possible, branches should be =E2=80=9Cstateless=E2=80=9D in the sense th= at their changes >> can be rebased anytime on top of =E2=80=98master=E2=80=99. This is what= we=E2=80=99ve been >> doing for the past couple of months with =E2=80=98core-updates=E2=80=99;= 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. Initially the documentation on branches said to create an issue when you want to merge a branch, but this was changed to when you create a branch to try and avoid situations like this, where a branch sits around and gets stale for many months. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmbUnx5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcVCw/+OuOu9mnfm/NSLOrFyce0imZ2CtWBT6Oj NMwzU9KDH6k2Ttp/M5eAg4HlRa3II+T3QjoSuOQDn5JarWMH/OtdGhPlGNBBbfCj Yk2osQ2ODHEJS29KUIyIsO05oeWc1TLGQYxSoc//4FopB7CWQ7rgSyvDyzDN2tAm ak/SGTjWaoFQF8K/s4YUM635ddbhhN+3IUba3Ycg926mrRsXQgI5qqVSUuhxDqRy 9cQ6+wc8Xj2e/DtQWLax0ChH78xNiICLfAyO7h5gCogZIA9hHa2tRrbvUq/jf+l9 v4sZAAu5WCrL62g9crKKvdOC0LZ4a1Rha10dnN+FuTO+7wdY+LXD57TD5HQ5YejR hG8zEB1iluKT5sDYs8aM/8kqpsYEAU/aFTTm7azc0amY2mwenZgFOTGPgUnXTbM8 elA+/EHHeW/dD8cQrECB/ZpDVqGjpxY3s6Yy5CJwBRRG0pr0K9ziRPkU+S4KLM6Q 7w7n8/X4GsQmbFKWzqv/TTtmGIs0zakjF62Vb8+hhcAQ3ZiNv8KadYyaR3A8wGfw aiVmo8GFtGpaIOgwfyorvtLvZVx6PFvPNfLAsjXy51gVHz8ZQqeD+Sz+7BWG8GL6 3pfK5oZgYULNWt3u0jJkHph56GH8jVWCYalW7tBFVaf2g2fwwBXxtDr0eHZ9mlJY ZqsC+nUNrXY= =4MUF -----END PGP SIGNATURE----- --=-=-=--