From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id GAI6CxeyXmdubwAAe85BDQ:P1 (envelope-from ) for ; Sun, 15 Dec 2024 10:40:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id GAI6CxeyXmdubwAAe85BDQ (envelope-from ) for ; Sun, 15 Dec 2024 11:40:23 +0100 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=1734259222; 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=rOugHILdp2LPEe1zypNxJ6SWDfqkcM8p/4Tq8kpKQqk=; b=X5T2XtIRlmfIgCzX6WsfdRYFY30DSofJuw5djxeVAf3uqcghoe+yR3iuyJJC8PV0vEfYqB gRx1JMHao3UrRlretovn6vfEyqagAshTzD4yJYuiQjqsDjaWlFN1CgE6WxalQPkB4exU8+ yagNSyGwrlGOQYWAJE2LX9rVm3RCOvl75Gp/5NGv6Qvxl0GEK2L7L7GqfBubKEd2C6/gck rW8nRo3tBrG/Le4T80K/MyaG0J3JhmEbBuQ4gogrRG74yE0Ua9da+cELao3rds/RpVoxHh u+ndfQX4qywYKRYPjLz53U5wnB5oufNfe/i5CoHLi8bytVHy98exnbj3grHxaA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734259222; a=rsa-sha256; cv=none; b=hgQvoB/f+ckMFz7w1ZbO/CccBd1Qen/SRBivYs06RtPHud8UzKXlTY4tS5pM/uVcUWfjh0 g8WMnSOU3pkInuNuiqVSyTnjv25AlUzGDvpVH5J6c7Xt2KAdvCKBE8+SYbL9c96McEhcyd 91dFqFwRpoSEKx8oOipUf/nxQmucIwIYrK4f1ykJIJImrH2RQ/5VdYS/Jjvuo0/ufoR/cg X5eSmabyLjTfrQvFbEBC9A2sWElt8SxT/dAGFQUjxunz2Qo0f39VgFvtvig44O7gJ4fQrk PFsTHVgs6cB566gaLgCsaqMr7u+pkxnuCWmbymUi9fthdzNLKYJve2BCoA+xcQ== 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 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 C6A9379F37 for ; Sun, 15 Dec 2024 11:40:22 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMm2a-0006Ap-8f; Sun, 15 Dec 2024 05:40:00 -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 1tMm2X-0006AX-EG for guix-devel@gnu.org; Sun, 15 Dec 2024 05:39:57 -0500 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMm2T-0003Lv-Rd; Sun, 15 Dec 2024 05:39:56 -0500 Received: from localhost (unknown [IPv6:2a02:6b67:e390:8b00::1ce5]) by mira.cbaines.net (Postfix) with ESMTPSA id 8200D27BBE2; Sun, 15 Dec 2024 10:39:48 +0000 (GMT) Received: from fang (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 05ec3c94; Sun, 15 Dec 2024 10:39:47 +0000 (UTC) From: Christopher Baines To: Janneke Nieuwenhuizen Cc: Maxim Cournoyer , Steve George , 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: <87ttb5e587.fsf@gnu.org> (Janneke Nieuwenhuizen's message of "Sun, 15 Dec 2024 09:10:48 +0100") References: <87le0cj13e.fsf@inria.fr> <87v7zfuwv5.fsf@cbaines.net> <87bjxdzjdh.fsf@gmail.com> <87ttb5e587.fsf@gnu.org> Date: Sun, 15 Dec 2024 10:39:45 +0000 Message-ID: <87h675mdqm.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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -4.28 X-Spam-Score: -4.28 X-Migadu-Queue-Id: C6A9379F37 X-Migadu-Scanner: mx11.migadu.com X-TUID: 2K4RZdQhpUAJ --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Janneke Nieuwenhuizen writes: > Maxim Cournoyer writes: > >> Sorry for reviving a 14 weeks old thread, I'm still catching up >> post-move :-). > > Ah that explains why I missed this... > >> Christopher Baines writes: >> >> [...] >> >>>> 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= that their changes >>>>> can be rebased anytime on top of =E2=80=98master=E2=80=99. This is w= hat 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. >> >> Hm. So is the intention that the moment a branch is created, it is >> expected to be in a good shape to be merged? > > [..] > >> For multi-people team endeavours (e.g., GNOME, although Liliana has been >> doing most of the work (thanks!)), it seems a bit unreasonable to expect >> the branch to be ready from the moment it lives. > > That's the case with the current `core-packages-team'; sorry I if > derailed this fresh new policy/idea just after it was conceived... > > The `core-packages-team' branch focusses on the gcc-14 transition, so > that we may offload to 64bit childhurds: the 64bit Hurd needs gcc-14 and > updating gcc for one architecture/platform only was rejected as overly > complicated. This means, however, that while I'm looking mainly at > x86_64 and reconfigure'ing my system on `core-packages-team', Efraim has > been looking at the impact on other architectures. I don't see how we > would co-ordinate our efforts without a common work-in-progress branch? > > We've been seeing a regular stream of `squash' commits fixing our and > eachother's patches and I'm keeping `core-packages-team' rebased > regularly and hope that we don't need to merge it once it's ready, but > can just push the final rebase. I think what you're doing is fine. the only thing I'd suggest to change is regarding branch naming. This isn't documented, but data.qa.guix.gnu.org (and QA) ignore branches where the name begins with wip-. So if as you say this branch is currently being worked on, but not quite ready to be merged, then I'd suggest naming it as wip-core-packages-team (or anything else beginning with wip-). That way, the data service will ignore it and can spend it's time looking at other branches/patch series. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmdesfFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcehhAAhLEeWITFX6lj3EKV5Uep7SM6s+S0DWKj 08xfkG6crTCfR9hohXYYtpW0L2UMS0/U96ycAVw7PtbJVPo9BOmUOls7Cyfm+hfu hGkZ6uav68LcDbTXNK+FdRPfvg7VBCeCQmgCeQQVfjNq3WohR7oV/XPTkPg+aBrR jHzcovkGgOEApB2ecJjMyaSMRnYFqDspbJbFsWQdev1HOCWr4BJKrDAdJ2IwKI4i OAv6lOoRYC3I2oIPelS+9nBl+Huk5eXY3LXt1xaiM1lnVyIDOirUcBFXHHh0/8FJ yiGBq0B12pLQJuXCkwvBi0tQWHUqZKTcOa88jkb6smDFsgU3qn7RPkIwrVeIiCEC IGYywizVJ4HZbs6NX3IBHP4GAXADzInn/2fknyTkNkPFnyMt58+4o5BlAP0JTJ8k /S6lNQ/UyVXWltf476uAylGB25/8dB7wViNaXTj76SiJQR09pIQgopQLZfxQQ0t6 9v5SQ+MA4SGIeJNFJBYsbDOyjyKWdhtsDKVTWSMpCbBKXeKNX31anzclA9vscGcL Aye1CkHq5VqSXRqaUlnhM1X+1Wm9BOa1xE1KxSG91lgp5zMUDRRnPP49IYe1Qyg6 0ON+5ZOB1LbUF2QUJKjQFOn8I0Dkp5QJx7yrjDFt5csx0CUN7ht3zAt7OBeHlVXV A+t9QHbCLFY= =OtdR -----END PGP SIGNATURE----- --=-=-=--