From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.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 8C/DJuSqXmceGQAAe85BDQ:P1 (envelope-from ) for ; Sun, 15 Dec 2024 10:09:40 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 8C/DJuSqXmceGQAAe85BDQ (envelope-from ) for ; Sun, 15 Dec 2024 11:09:40 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; 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-Seal: i=1; s=key1; d=yhetil.org; t=1734257380; a=rsa-sha256; cv=none; b=bcMPFu9fYBUYWVPcLqzz8ZUw66b5SJLvSySAu4uENz6wodf0HH/i/n34HGEKlTvooQRmPN A/1+bwU9y4qlAbLB0S7eYuXIJJkSD6MCTYhkSkv46+Nn8pjjRxGmqtG0HhR7RmwTNCnedY ++IRTfGjX0d+pB5yNYHg9x+wOBSmY54ZsWvbeBosjpvxXea3U7RAEQ1ekH6pA2CPjy1I5r M6X7PJ4LysPKgvqwsq6duD4JBfAapT4RwvMUyKBKo7aFymMSGpqyiJxkK3srVNFrjaXsoJ sOx+nFUWbfUzQRAg8d3Kjr0dIx9VmvFS1B6M/AduF27Z/6V/A/f3BnDpr8hlDA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=1734257380; 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=wRCKt40UgauV4EZ2g6ActybIPS3AKMW+kZTH5XhvNzw=; b=OxjP72+1cELDVqtk7vVPuYouJYBrOZVsTBF6kaOEXM7m4MJjSoilOhdenvMnjWrNABzl64 Mhg8nq3RRdqcuuQhdlOfcT/WQMFBE6m2g/71p5bXNxiY2nesNHbjmuQNYT1i3jMqCOAji9 wjh6yQ6OX6SnrqRcbndmQT8hcmNxxHF8MJQwmq1bOTc015U3Q46PboRlCLoKAHmJfUFnYb VwYC8iUVSyVemnGukXs8jgZmt6Rz9/yobWUrmolZcksxWodIUcJXojvgQxHQPRyIEuCKQk AX1jpTE0ictXrqSD8rKSG4VpOLeJurTYNS6TDndtu4XSXdZeQMm5bRSkCJBN2A== 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 4213D19B70 for ; Sun, 15 Dec 2024 11:09:40 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMlYi-0001cp-V1; Sun, 15 Dec 2024 05:09:09 -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 1tMlYd-0001cC-Pg for guix-devel@gnu.org; Sun, 15 Dec 2024 05:09:04 -0500 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMlYb-0007DG-1r; Sun, 15 Dec 2024 05:09:03 -0500 Received: from localhost (unknown [IPv6:2a02:6b67:e390:8b00::1ce5]) by mira.cbaines.net (Postfix) with ESMTPSA id D549827BBE2; Sun, 15 Dec 2024 10:08:52 +0000 (GMT) Received: from fang (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 97a73e45; Sun, 15 Dec 2024 10:08:51 +0000 (UTC) From: Christopher Baines To: Maxim Cournoyer Cc: 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: <87bjxdzjdh.fsf@gmail.com> (Maxim Cournoyer's message of "Sun, 15 Dec 2024 12:59:38 +0900") References: <87le0cj13e.fsf@inria.fr> <87v7zfuwv5.fsf@cbaines.net> <87bjxdzjdh.fsf@gmail.com> Date: Sun, 15 Dec 2024 10:08:49 +0000 Message-ID: <87ldwhmf66.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -6.78 X-Spam-Score: -6.78 X-Migadu-Queue-Id: 4213D19B70 X-Migadu-Scanner: mx12.migadu.com X-TUID: 1aUsUMH7vK1F --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maxim Cournoyer writes: > Hi Chris, > > Sorry for reviving a 14 weeks old thread, I'm still catching up > post-move :-). No worries, I hope move things are going well. > 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 wh= at 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 f= or >>>> 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? The previous way seemed > more natural to me; the 'request for merge' issue would be created when > the branch was mostly built or at least tested and deemed ready for > being merged. Now we won't know; we will depend on the person creating > the branch being around to let us know of its state (plus the QA/CI > indicatorcs of course). > > 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. So, I think the "you must create a new guix-patches issue each time you create a branch" makes more sense in the context of [1] which is also suggesting that branches are just the combination of one or more patch series. 1: https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Bran= ches.html As I say above, my hope with this is that it would help avoid long running branches which could become harder to work with. I think this also makes sense in the context of the limited resources we have, in particular time/hardware for building things for non-x86_64-linux architectures. Rather than building all branches that people are working on for all architectures, it's more useful to focus on building the branches that people think are ready to merge. One change I also made at some point is that the data service/QA ignore branches prefixed with wip-, so while this currently isn't mentioned in the docs (maybe it should be), one workflow currently is to create a wip-foo branch and iterate on that, and then when it's ready, push the changes as foo and create the merge issue. Going back to your concerns about testing branches/changes before you think they're ready to merge though, I definitely think there's room for improvement in tooling and processes in this area though. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmdeqrFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcXhA/8CtTa75APzqtU+WB6UgMu3eudLuWzKQ99 X8Gr5tRARerLdVzRRO/m0a8ISLq1CfSVvmf04wnGxSrM/fy8dAA8Qr/0IVNdFXR5 a5OwLUB98Rg2DbyEvYhLBmZ4+xs3aCSKJHpiKpKxj38k3BWiTCJY3PmOj03/mbF1 uIFbFlUlkYDb4QVvTAUh6IbSYNFCH/hKPrIsz+93+q/j7vJh0lgghXUxUyTNJPxw T6ldgT+bF2KHc4SKpoAgMJTayZq7PIQC6bFd+qbLZooz7WwNhklmws8Tur4RhHuu s0Hq7HFDSdh2cQgrl00sGI7LTz0oVH3fXPjIu2cwU8ltKGXdMVIuxF6WecndtO+k 2S2Vt8gi4XV5DvTiMIi512nQvcoNTpDQGyuUZo1eJUxGOgHGbU0yGaUl4EETxqRQ RoPD14Z9+Id2DyGjJWTYCK9rYG0prhjQ7m9Tu3F5UbpcSPdRWxbQoDrj8ewjGpEA QhI/bvuLp9eE44yhCPhr/EzTvxlUP8QOc15GHok4yro81+STf0qFynzhGgTvHLJx e+a6X9J515P2OJwyDlqoB2XoE2A/GqP+MlELBz4qhkinmScoT5ns9cKqGVi1NYHW UbrvEAvpIDQ+UbxvjPYn+hyvgwetQyv1FclTL26ErK+dwVnm49YI6lIx9mNYH4Sq Zxcw4NgpGVI= =iYmJ -----END PGP SIGNATURE----- --=-=-=--