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 iLmLAHMDX2cFBAAA62LTzQ:P1 (envelope-from ) for ; Sun, 15 Dec 2024 16:27:31 +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 iLmLAHMDX2cFBAAA62LTzQ (envelope-from ) for ; Sun, 15 Dec 2024 17:27:31 +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=1734280050; a=rsa-sha256; cv=none; b=fYM/L/k55NqOvZC+IdVahZNtevuvE1u0R/4W4MGG+Z91Ajasn5vY8wSP4vkZ4A+TNwinut V/rb/J10owkhk60olHNXyrdoHLoxB75IvcHWKBRl36yvChopeHB7SbLlWKr29qRrAbcwL8 G/7zzb65uWksA+iy1z7xJ3XXnndnh009TqU5aHMmLQEWi1SQQkBX62gdYdxj8M8puqJyBO go1f760zJMT/0D9YZoiCwhn+VOwBY4yQs/h3ASVCnF9VnkKJ4puPyTezTfE8xsYhT+p5t5 a5aunOvSbFSoI33G6QUAbJWHJbWArlBj/iFDYrJ1Aq0xx0r6STiXbRtNj8Y98Q== 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=1734280050; 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=WqdYsk/GIMEnMNI/ibs68GtfkBJzTFZWRWXxU1R89S8=; b=JSkXylmCn7Y2UO7rMNldBaRg2DFVyslmDWX0CFrSzbAOV2ktOikOnvx6vRi1QZTp8Ay0oN SIkRRwObENdttq4Alifl937iPeM+5uBiqelcmahbmwFNkwlG5RPhrP7Pqv4Lxi5WXVcHj2 kMrQcQCwB5OT1fMRXy3kvRWRzR/fQMDGDIYnEdz/pSi7IBXmTSkyoDG3zXv9DSnYRJy/dI JzKac/f2vUfcNWAYQFwaYC/ztMDAhCc/2juQfRv8bk91EQZrdJKA2lL/x8RfeySwIbZvp6 vxO5k3JUsotH6wk9Syyb1wvhU84CpQTxrPCr94UBKoLk49LtwjdZKQNUjDKQ7Q== 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 91490960B5 for ; Sun, 15 Dec 2024 17:27:30 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMrSC-0003tH-G8; Sun, 15 Dec 2024 11:26:48 -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 1tMrS5-0003su-0P for guix-devel@gnu.org; Sun, 15 Dec 2024 11:26:41 -0500 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMrS2-0006XC-PS; Sun, 15 Dec 2024 11:26:40 -0500 Received: from localhost (unknown [IPv6:2a02:6b67:e390:8b00::1ce5]) by mira.cbaines.net (Postfix) with ESMTPSA id 8757227BBE2; Sun, 15 Dec 2024 16:26:32 +0000 (GMT) Received: from fang (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 36610b47; Sun, 15 Dec 2024 16:26:31 +0000 (UTC) From: Christopher Baines To: Maxim Cournoyer Cc: Janneke Nieuwenhuizen , Steve George , Ludovic =?utf-8?Q?Court=C3=A8s?= , guix-devel Subject: Re: work-in-progress team branches In-Reply-To: <87msgxvy8j.fsf_-_@gmail.com> (Maxim Cournoyer's message of "Sun, 15 Dec 2024 23:04:28 +0900") References: <87le0cj13e.fsf@inria.fr> <87v7zfuwv5.fsf@cbaines.net> <87bjxdzjdh.fsf@gmail.com> <87ttb5e587.fsf@gnu.org> <87h675mdqm.fsf@cbaines.net> <87msgxvy8j.fsf_-_@gmail.com> Date: Sun, 15 Dec 2024 16:26:31 +0000 Message-ID: <878qsgnc94.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27; 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 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: -7.59 X-Spam-Score: -7.59 X-Migadu-Queue-Id: 91490960B5 X-Migadu-Scanner: mx10.migadu.com X-TUID: OSPvEGfDZZOP --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Maxim Cournoyer writes: > Hi, > > Christopher Baines writes: > > [...] > >>>> 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 be= en >>>> doing most of the work (thanks!)), it seems a bit unreasonable to expe= ct >>>> 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. > > I see; that sounds workable, although it was nice to get > substitutes for the 'gnome-team' branch even though it was a WIP (in the > sense that we weren't sure the new reviewed commits would > build/integrate fine before pushing them to the gnome-team branch). > We'll need to register another branch (the wip-* one) to Cuirass for > this use case I guess. > > Does the following doc addition makes sense? I've placed it at the end > of the 'Managing Patches and Branches' section: > > --8<---------------cut here---------------start------------->8--- > 1 file changed, 11 insertions(+) > doc/contributing.texi | 11 +++++++++++ > > modified doc/contributing.texi > @@ -2362,6 +2362,17 @@ Managing Patches and Branches > Once the branch has been merged, the issue should be closed and the > branch deleted. >=20=20 > +@cindex work-in-progress branches, wip > +@cindex wip branches > +Sometimes, branches may be a work in progress, for example, for larger > +efforts such as updating the GNOME desktop. For such cases, the branch > +name should reflect this by having the ``wip-'' prefix. The QA > +infrastructure will avoid building work-in-progress branches, so that > +the available resources can be better focused on building the branches > +that are ready to me merged. When the branch is not longer a work in > +progress, it should be renamed, with the ``wip-`` prefix removed, and > +only then should the merge requests be created, as documented earlier. > + > @node Debbugs User Interfaces > @subsection Debbugs User Interfaces > --8<---------------cut here---------------end--------------->8--- Yep, sounds reasonable. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmdfAzdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9Xd9vA/+MY+T/3/DRcBU2OyvaqLjtrkY4wD6/mr6 +Uk/2ThQ0tgs43rApEexO80S5QX5nw3Ksv59wJqxziSoC7X/oLraW8DIRCiMdWRE 5CQVLyJPDLdniC/iwbpk2XxERBC5BNcmNJv54HwUcF5NixWe2rSjRZzLf6xCDWxG BL8fn4W2gvNSN6FtubkkRxYxKiG5U6rr5KZI0uJzvEaI4cG6FRdL6QfRqKiPsiyW 8UzauqF6SU/MYoM6Jk4fm+l4S6XSK/7UCrRPo1tcfwYHk8hmgcr6oZVD15IzvuuI vrmSKBkalGmlJGW/Tn9uY7YN0B11G3xDi4fKKKcs6HlLEcwq1UAQL8MePp1QrGBj cngFWanGDJcGSrQp0Dr1kGggmGTFSnU5m1xCbVBknhnNmGyRcTsusnrUimHk+9Jq KDwArzNBXrXS4VIZ8X275W2EYcfAxqzVTurexgrj0SpxgiIKjd/FOjOoVr6xRB9Y nofpx9iYI3bNWbD26/dxfA0WyZ9jWpWipBXrmXGM7+froS7oc5pXGLa+NSPXoCXg Aev1y3yrApUSL3StSsshBRXBY0AqUQYnQ1vixJSom7kqvJhhBax0sVV5Grze6Iq/ MWKfd6EjUujYvFnSNE1Eo6imH6YZxzzAJGFNNOlf4CCsxm8RC2YReXY7H6NdXY6V zo0q2ZSDjl0= =54XG -----END PGP SIGNATURE----- --=-=-=--