From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 12 May 2023 07:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 63459@debbugs.gnu.org X-Debbugs-Original-To: guix-patches@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16838781304572 (code B ref -1); Fri, 12 May 2023 07:56:01 +0000 Received: (at submit) by debbugs.gnu.org; 12 May 2023 07:55:30 +0000 Received: from localhost ([127.0.0.1]:53999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNcf-0001Be-SE for submit@debbugs.gnu.org; Fri, 12 May 2023 03:55:30 -0400 Received: from lists.gnu.org ([209.51.188.17]:33922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNce-0001BO-CC for submit@debbugs.gnu.org; Fri, 12 May 2023 03:55:28 -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 1pxNcc-0002EQ-41 for guix-patches@gnu.org; Fri, 12 May 2023 03:55:27 -0400 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pxNcZ-0001XK-QU for guix-patches@gnu.org; Fri, 12 May 2023 03:55:25 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id 16AAB27BBEE for ; Fri, 12 May 2023 08:55:21 +0100 (BST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 5b211ca9 for ; Fri, 12 May 2023 07:55:20 +0000 (UTC) From: Christopher Baines Date: Fri, 12 May 2023 08:55:20 +0100 Message-Id: X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Move away from using staging and core-updates, and make the strategy independant of branch names. Keep the 300 dependent threshold for changes to master, as I don't have any specific reason to change this. Most importantly, require using guix-patches issues to coordinate merging of the branches, as I think that'll address the key issues that have shown up recently where it's been unclear which branch should be merged next. * doc/contributing.texi (Submitting Patches): Rewrite branching strategy. --- doc/contributing.texi | 58 +++++++++++++++++-------------------------- 1 file changed, 23 insertions(+), 35 deletions(-) diff --git a/doc/contributing.texi b/doc/contributing.texi index 7bf350ee0d..c54910e34d 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -1264,41 +1264,29 @@ Submitting Patches @c See . @cindex branching strategy @cindex rebuild scheduling strategy -Depending on the number of dependent packages and thus the amount of -rebuilding induced, commits go to different branches, along these lines: - -@table @asis -@item 300 dependent packages or less -@code{master} branch (non-disruptive changes). - -@item between 300 and 1,800 dependent packages -@code{staging} branch (non-disruptive changes). This branch is intended -to be merged in @code{master} every 6 weeks or so. Topical changes -(e.g., an update of the GNOME stack) can instead go to a specific branch -(say, @code{gnome-updates}). This branch is not expected to be -buildable or usable until late in its development process. - -@item more than 1,800 dependent packages -@code{core-updates} branch (may include major and potentially disruptive -changes). This branch is intended to be merged in @code{master} every -6 months or so. This branch is not expected to be buildable or usable -until late in its development process. -@end table - -All these branches are @uref{https://@value{SUBSTITUTE-SERVER-1}, -tracked by our build farm} and merged into @code{master} once -everything has been successfully built. This allows us to fix issues -before they hit users, and to reduce the window during which pre-built -binaries are not available. - -When we decide to start building the @code{staging} or -@code{core-updates} branches, they will be forked and renamed with the -suffix @code{-frozen}, at which time only bug fixes may be pushed to the -frozen branches. The @code{core-updates} and @code{staging} branches -will remain open to accept patches for the next cycle. Please ask on -the mailing list or IRC if unsure where to place a patch. -@c TODO: It would be good with badges on the website that tracks these -@c branches. Or maybe even a status page. +Changes to packages with 300 dependent packages or less can be pushed to +the @code{master} branch. + +Larger changes should be first pushed to a branch other than +@code{master}. This allows for testing and for the build farms to +process the changes prior to being pushed to the @code{master} branch. + +To help coordinate the merging of branches, you must create a new +guix-patches issue each time you wish to merge a branch. These issues +indicate the order in which the branches should be merged, so take a +look at the open issues for merging branches and mark the issue you +create as blocked by the issue previously at the back of the queue. + +Normally branches will be merged in a ``first come, first merged'' +manor, tracked through the guix-patches issues. If you agree a different +order with those involved, you can track this by updating which issues +block which other issues. Therefore, to know which branch is at the +front of the queue, look for the issue which isn't blocked by any other +branch merges. + +Once a branch is at the front of the queue, wait until sufficient time +has passed for the build farms to have processed the changes, and for +the necessary testing to have happened. @item @cindex determinism, of build processes base-commit: 9d05f9a9f538061e1fdc5aedb0748d260fcf20f7 prerequisite-patch-id: ae24e25c683be86ce0b3fa1fde1bd30e3e08e248 -- 2.39.1 From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 12 May 2023 08:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: guix-devel@gnu.org Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16838789846010 (code B ref 63459); Fri, 12 May 2023 08:10:02 +0000 Received: (at 63459) by debbugs.gnu.org; 12 May 2023 08:09:44 +0000 Received: from localhost ([127.0.0.1]:54021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNqS-0001Ys-JU for submit@debbugs.gnu.org; Fri, 12 May 2023 04:09:44 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNqQ-0001Yk-JZ for 63459@debbugs.gnu.org; Fri, 12 May 2023 04:09:43 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id 7E45027BBEE; Fri, 12 May 2023 09:09:41 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id f98782b4; Fri, 12 May 2023 08:09:41 +0000 (UTC) References: User-agent: mu4e 1.8.13; emacs 28.2 From: Christopher Baines Date: Fri, 12 May 2023 09:04:40 +0100 In-reply-to: Message-ID: <87zg6aq8cd.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Christopher Baines writes: > Move away from using staging and core-updates, and make the strategy > independant of branch names. > > Keep the 300 dependent threshold for changes to master, as I don't have any > specific reason to change this. > > Most importantly, require using guix-patches issues to coordinate merging of > the branches, as I think that'll address the key issues that have shown up > recently where it's been unclear which branch should be merged next. > > * doc/contributing.texi (Submitting Patches): Rewrite branching strategy. > --- > doc/contributing.texi | 58 +++++++++++++++++-------------------------- > 1 file changed, 23 insertions(+), 35 deletions(-) Following on from the discussion recently about moving away from staging and core-updates, I've sent a patch to update the branching strategy. The key thing is obviously to just remove mentions of staging and core-updates, making the guidance more generic. However, I've also added some requirements to use guix-patches issues to track the intentions to merge branches, as I think that'll help address some of the issues that came up recently with uncertainty around which branch will be merged next. I'm also hoping that these issues then can be used to automate the QA process, triggering the qa-frontpage to automatically start building the relevant branches. Thanks, Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmRd9EJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XfaCg/+IERRc0uIrPqRNsjEkPBfOMp9HbWr658a GGo8lI2FcbhKgZLJN+cGahEz1QE4g+mms4IS1LoUP5OFgk1OfMR6gmMEFOJ7DT/7 2SvF3R8tBxxwDlceVW+IBXVQa+QvFAyzmLf4+8UdKcTTD/fU2fX3K5IY3277uH5c o+gFgqY4jnLaO2dEy69MnhgkIe1YOJGVfRDt7NSkGhRdHRgGFyQX7Chq082koC3D z8o2rNujInn5UvvPV2xQ4KtKyqbt0Z3iwxSFe+7C8a4/++48BpfHj/3dYa3W1awc fn348DJHnCUKlRxZ5Q7Bum83XDdpw9xLnNy1sfu7aMoHGgvi1sKqmFpoqsFBmDak 4Mk5ssEIWuL0h7QRL9jYy2+PW4DCoe1GwywL5jTsPKrbnI2Cu9660UyKiGeLhR9M 2rKsq96NplYE+Mdp//im8ImLMlmaelw7ahCXGvgdTqW8ApjzQoi7Csa52/qTg6D+ JLIlGNlpI2I0CBntC+nWnI7yQ38/nSDh9yIphtIZ4q38v3TJ1VOxmq7gi2RHrb9T myv+y1lD1NCf2QOqhJrbGLNbICNsv274gJvpsalOswSFxSJTZxg5Wn5Kuvor7XU2 yzs2UDfgfdLVTo1Nz/VbYzeILYCK9QDwHRh7gxpEDV0QWq2IKa8iyyFuR0KDncSO t2BBj4m57g0= =fYcw -----END PGP SIGNATURE----- --=-=-=-- From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 19 May 2023 13:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Christopher Baines Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16845025902773 (code B ref 63459); Fri, 19 May 2023 13:24:02 +0000 Received: (at 63459) by debbugs.gnu.org; 19 May 2023 13:23:10 +0000 Received: from localhost ([127.0.0.1]:55690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q004b-0000ie-QJ for submit@debbugs.gnu.org; Fri, 19 May 2023 09:23:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q004Z-0000iR-Lg for 63459@debbugs.gnu.org; Fri, 19 May 2023 09:23:08 -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 1q004U-0004Br-Ce; Fri, 19 May 2023 09:23:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=0VSrPraE1tSg3olpOYQs+rQX6BSEZCwZGf+KAuRqlCo=; b=kb2Px/r3YTcu6J13tOM2 P8/y4agI2P2RBTiVbDlxfqTw+XV6rY/TqMKhOXkHkvKTlsCPdyGxaqjahCwGcZH/WMDIobnAeyuYj dxXdbHQ0f3zo00JVJqSRDnykCJPYFbwPy1LR0dV8ARlyRXyDdBNQZ/+ESG0U7qxVUX7xk+6ehznzY Nwjclxk6u5NRq/QPbjSPU9k7tl2UMBy/rQYxqY2U/y0nC4C4aMXz6tgbgmabD5W55RbYaO4fx5NKR txBDuHJZTedWIfbfvUU6RLp+Rhx8GYhJhLPzA3R6W+fv8mBnGytXU/MEXbNCifljy+7I82Kdks/nS DQCvLAz/YL0Qyg==; Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201] helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q004T-0001xj-Vr; Fri, 19 May 2023 09:23:02 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: Date: Fri, 19 May 2023 15:22:59 +0200 In-Reply-To: (Christopher Baines's message of "Fri, 12 May 2023 08:55:20 +0100") Message-ID: <87y1lkzc98.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hello, Thanks for this initiative! Christopher Baines skribis: > Move away from using staging and core-updates, and make the strategy > independant of branch names. > > Keep the 300 dependent threshold for changes to master, as I don't have a= ny > specific reason to change this. > > Most importantly, require using guix-patches issues to coordinate merging= of > the branches, as I think that'll address the key issues that have shown up > recently where it's been unclear which branch should be merged next. > > * doc/contributing.texi (Submitting Patches): Rewrite branching strategy. [...] > +Changes to packages with 300 dependent packages or less can be pushed to > +the @code{master} branch. > + > +Larger changes should be first pushed to a branch other than > +@code{master}. This allows for testing and for the build farms to > +process the changes prior to being pushed to the @code{master} branch. I=E2=80=99d be more specific: Larger changes should first be pushed to a topic branch other than @code{master}; the set of changes should be consistent---e.g., ``GNOME update'', ``NumPy update'', etc. This allows for testing: the branch will automatically show up at @indicateurl{https://qa.guix.gnu.org/branch/@var{branch}}, with an indication of its build status on various platforms. =E2=80=9CAutomatic=E2=80=9D is a bit of an overstatement; that sentence pro= bably needs to be tweaked. :-) But I think it=E2=80=99s good to link to the QA platfo= rm to make things more concrete. > +To help coordinate the merging of branches, you must create a new > +guix-patches issue each time you wish to merge a branch. These issues ^ + (@pxref{Tracking Bugs and Patches}) > +indicate the order in which the branches should be merged, so take a > +look at the open issues for merging branches and mark the issue you > +create as blocked by the issue previously at the back of the queue. s/blocked/@dfn{blocked}/ Perhaps add a footnote or paren stating how to =E2=80=9Cblock=E2=80=9D an i= ssue in Debbugs? > +Normally branches will be merged in a ``first come, first merged'' > +manor, tracked through the guix-patches issues. If you agree a different s/manor/manner/ s/agree a/agree on a/ > +order with those involved, you can track this by updating which issues > +block which other issues. Therefore, to know which branch is at the > +front of the queue, look for the issue which isn't blocked by any other > +branch merges. > + > +Once a branch is at the front of the queue, wait until sufficient time > +has passed for the build farms to have processed the changes, and for > +the necessary testing to have happened. This is a bit technical. How can I know =E2=80=9Cwhich branch is at the fr= ont of the queue=E2=80=9D? Even as a seasoned Debbugs users, I=E2=80=99m not s= ure what I=E2=80=99m supposed to do here. Do you think we could provide ready to use commands (debbugs.el or =E2=80=98mumi=E2=80=99) or at least a sequence of s= teps to follow? Last but not least: two spaces after end-of-sentence period please. :-) This is mostly about tweaking words; I think this is a great step forward, very much in line with what was discussed in February at the Guix Days. Thank you! Ludo=E2=80=99. From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 23 May 2023 17:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.168486443821799 (code B ref 63459); Tue, 23 May 2023 17:54:01 +0000 Received: (at 63459) by debbugs.gnu.org; 23 May 2023 17:53:58 +0000 Received: from localhost ([127.0.0.1]:40388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q1WCs-0005fW-8q for submit@debbugs.gnu.org; Tue, 23 May 2023 13:53:58 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q1WCp-0005fM-Lx for 63459@debbugs.gnu.org; Tue, 23 May 2023 13:53:56 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id 1223227BBE2; Tue, 23 May 2023 18:53:54 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 125d860e; Tue, 23 May 2023 17:53:53 +0000 (UTC) References: <87y1lkzc98.fsf@gnu.org> User-agent: mu4e 1.10.2; emacs 28.2 From: Christopher Baines Date: Tue, 23 May 2023 18:28:18 +0100 In-reply-to: <87y1lkzc98.fsf@gnu.org> Message-ID: <87pm6rlys0.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Hello, > > Thanks for this initiative! > > Christopher Baines skribis: > >> Move away from using staging and core-updates, and make the strategy >> independant of branch names. >> >> Keep the 300 dependent threshold for changes to master, as I don't have = any >> specific reason to change this. >> >> Most importantly, require using guix-patches issues to coordinate mergin= g of >> the branches, as I think that'll address the key issues that have shown = up >> recently where it's been unclear which branch should be merged next. >> >> * doc/contributing.texi (Submitting Patches): Rewrite branching strategy. > > [...] > >> +Changes to packages with 300 dependent packages or less can be pushed to >> +the @code{master} branch. >> + >> +Larger changes should be first pushed to a branch other than >> +@code{master}. This allows for testing and for the build farms to >> +process the changes prior to being pushed to the @code{master} branch. > > I=E2=80=99d be more specific: > > Larger changes should first be pushed to a topic branch other than > @code{master}; the set of changes should be consistent---e.g., ``GNOME > update'', ``NumPy update'', etc. This allows for testing: the branch > will automatically show up at > @indicateurl{https://qa.guix.gnu.org/branch/@var{branch}}, with an > indication of its build status on various platforms. > > =E2=80=9CAutomatic=E2=80=9D is a bit of an overstatement; that sentence p= robably needs > to be tweaked. :-) But I think it=E2=80=99s good to link to the QA plat= form to > make things more concrete. That sounds fine to me. Everything apart from starting the builds is already automatic, and I want to automate that through the issues described here. >> +To help coordinate the merging of branches, you must create a new >> +guix-patches issue each time you wish to merge a branch. These issues > ^ > + (@pxref{Tracking Bugs and Patches}) > >> +indicate the order in which the branches should be merged, so take a >> +look at the open issues for merging branches and mark the issue you >> +create as blocked by the issue previously at the back of the queue. > > s/blocked/@dfn{blocked}/ > > Perhaps add a footnote or paren stating how to =E2=80=9Cblock=E2=80=9D an= issue in > Debbugs? Yeah, I'll try and write something. >> +Normally branches will be merged in a ``first come, first merged'' >> +manor, tracked through the guix-patches issues. If you agree a different > > s/manor/manner/ > s/agree a/agree on a/ > >> +order with those involved, you can track this by updating which issues >> +block which other issues. Therefore, to know which branch is at the >> +front of the queue, look for the issue which isn't blocked by any other >> +branch merges. >> + >> +Once a branch is at the front of the queue, wait until sufficient time >> +has passed for the build farms to have processed the changes, and for >> +the necessary testing to have happened. > > This is a bit technical. How can I know =E2=80=9Cwhich branch is at the = front > of the queue=E2=80=9D? Even as a seasoned Debbugs users, I=E2=80=99m not= sure what I=E2=80=99m > supposed to do here. Do you think we could provide ready to use > commands (debbugs.el or =E2=80=98mumi=E2=80=99) or at least a sequence of= steps to > follow? So, I think there's two technical hurdles to overcome here. The first is identifying the issues for merging branches, maybe for that we can set out a format for the title of the bug, but I'm very open to suggestions. Any way of identifying the open issues should be usable through debbugs.el and mumi. The second hurdle is the queuing behaviour, which I think the blocking behaviour is a natural fit for. Maybe the tooling is lacking but I think that can be addressed. I want the qa-frontpage to display the queue of branches (and issues) in a clear way, as well as providing links to make changes (as it does for marking issues as moreinfo). > Last but not least: two spaces after end-of-sentence period please. :-) > > This is mostly about tweaking words; I think this is a great step > forward, very much in line with what was discussed in February at the > Guix Days. Thank you! Great, thanks for taking a look! Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmRs/a9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XeBSw/+IM3UMPClj0tdekh2kCo4rrbaBeCzB+hB IUPuXieF+P0BaDgE0YJdtmV3jL5tpUF36MBQ5CafVnP440YP4b0WOZtNSpYteHaZ z0FhU3Fe1U+YDiVWea3n8+pFawKR7Vqw2n03c32LZ5Z+j9NBchwgALBB8G96vxvc +yY6yZmMElNtvNiL4DoWtx6HNxi4EnmBLnDgorciAHXStCpyX3dvm3no7kPvNbLm acq88Q0mzOD5VaoPSBNWxsuN6fC9r+mhfisIVFeyH4fwE7yAYLKkXijZy5wcgGfd XfOznMOLOposZCRerCSPJbpoiYsZgN13dama1eAA8pnFaQqJkAbncGEkfWmz95mn R/LXh6rNSNnLBR7+E0IwHalun6D1FMcpqrgMJukakba9AgdOmPy4wKGgpUKJS84M cb21nM7hJRu0CuYuBi6AOfCY0+eSo9ttXBYVLCqkIOspgC2oCzuXFm56/BezeiHJ 3hecyZY/p0bCqfUrD6RiGS9igcmD9wUDbHazpN6+YDPNRfbnY+5YybktP+qDG/pT c1sRGvM6jmW+VqV6eqJzw/FkM1dS0z1nxjY2tOF54piC67quCXMFhe/8fm6dndfV QDuMvDTfkxhnPby3WRnf74QMx7SV4f/TznKTLzMJS4LKtE1D9fBwKXbwGIjNC1j+ THRVaxL6vK4= =uXXz -----END PGP SIGNATURE----- --=-=-=-- From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH v2] doc: Move and rewrite the branching strategy. References: In-Reply-To: Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 31 May 2023 09:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 63459@debbugs.gnu.org Cc: Christopher Baines Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16855260801049 (code B ref 63459); Wed, 31 May 2023 09:42:01 +0000 Received: (at 63459) by debbugs.gnu.org; 31 May 2023 09:41:20 +0000 Received: from localhost ([127.0.0.1]:34907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4IKV-0000Gq-KS for submit@debbugs.gnu.org; Wed, 31 May 2023 05:41:20 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4IKR-0000GZ-VH for 63459@debbugs.gnu.org; Wed, 31 May 2023 05:41:18 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id CC20527BBE2; Wed, 31 May 2023 10:41:14 +0100 (BST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 5f28fabd; Wed, 31 May 2023 09:41:13 +0000 (UTC) From: Christopher Baines Date: Wed, 31 May 2023 10:41:12 +0100 Message-Id: <9e9b6e968ab3faa7281d064cdfc59ef32adcf689.1685526070.git.mail@cbaines.net> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Move away from using staging and core-updates, and make the strategy independant of branch names. Keep the 300 dependent threshold for changes to master, as I don't have any specific reason to change this. Most importantly, require using guix-patches issues to coordinate merging of the branches, as I think that'll address the key issues that have shown up recently where it's been unclear which branch should be merged next. * doc/contributing.texi (Submitting Patches): Move the branching strategy to a new Managing Patches and Branches section. (Managing Patches and Branches): New section. (Commit Policy): Simplify through referencing the new Managing Patches and Branches section. Signed-off-by: Christopher Baines --- doc/contributing.texi | 140 +++++++++++++++++++++--------------------- doc/guix.texi | 14 ++--- 2 files changed, 76 insertions(+), 78 deletions(-) diff --git a/doc/contributing.texi b/doc/contributing.texi index f692872c04..96b22b7d9a 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -26,7 +26,7 @@ Contributing * Packaging Guidelines:: Growing the distribution. * Coding Style:: Hygiene of the contributor. * Submitting Patches:: Share your work. -* Tracking Bugs and Patches:: Keeping it all organized. +* Tracking Bugs and Changes:: Keeping it all organized. * Commit Access:: Pushing to the official repository. * Updating the Guix Package:: Updating the Guix package definition. * Writing Documentation:: Improving documentation in GNU Guix. @@ -1161,11 +1161,11 @@ Submitting Patches at the section on commit access (@pxref{Commit Access}). This mailing list is backed by a Debbugs instance, which allows us to -keep track of submissions (@pxref{Tracking Bugs and Patches}). Each -message sent to that mailing list gets a new tracking number assigned; -people can then follow up on the submission by sending email to -@code{@var{ISSUE_NUMBER}@@debbugs.gnu.org}, where @var{ISSUE_NUMBER} is -the tracking number (@pxref{Sending a Patch Series}). +keep track of submissions (@pxref{Tracking Bugs and Changes}). +Each message sent to that mailing list gets a new tracking number +assigned; people can then follow up on the submission by sending email +to @code{@var{ISSUE_NUMBER}@@debbugs.gnu.org}, where @var{ISSUE_NUMBER} +is the tracking number (@pxref{Sending a Patch Series}). Please write commit logs in the ChangeLog format (@pxref{Change Logs,,, standards, GNU Coding Standards}); you can check the commit history for @@ -1257,48 +1257,9 @@ Submitting Patches the @code{texlive-tiny} package or @code{texlive-union} procedure instead. @item -For important changes, check that dependent packages (if applicable) are -not affected by the change; @code{guix refresh --list-dependent -@var{package}} will help you do that (@pxref{Invoking guix refresh}). - -@c See . -@cindex branching strategy -@cindex rebuild scheduling strategy -Depending on the number of dependent packages and thus the amount of -rebuilding induced, commits go to different branches, along these lines: - -@table @asis -@item 300 dependent packages or less -@code{master} branch (non-disruptive changes). - -@item between 300 and 1,800 dependent packages -@code{staging} branch (non-disruptive changes). This branch is intended -to be merged in @code{master} every 6 weeks or so. Topical changes -(e.g., an update of the GNOME stack) can instead go to a specific branch -(say, @code{gnome-updates}). This branch is not expected to be -buildable or usable until late in its development process. - -@item more than 1,800 dependent packages -@code{core-updates} branch (may include major and potentially disruptive -changes). This branch is intended to be merged in @code{master} every -6 months or so. This branch is not expected to be buildable or usable -until late in its development process. -@end table - -All these branches are @uref{https://@value{SUBSTITUTE-SERVER-1}, -tracked by our build farm} and merged into @code{master} once -everything has been successfully built. This allows us to fix issues -before they hit users, and to reduce the window during which pre-built -binaries are not available. - -When we decide to start building the @code{staging} or -@code{core-updates} branches, they will be forked and renamed with the -suffix @code{-frozen}, at which time only bug fixes may be pushed to the -frozen branches. The @code{core-updates} and @code{staging} branches -will remain open to accept patches for the next cycle. Please ask on -the mailing list or IRC if unsure where to place a patch. -@c TODO: It would be good with badges on the website that tracks these -@c branches. Or maybe even a status page. +Check that dependent packages (if applicable) are not affected by the +change; @code{guix refresh --list-dependent @var{package}} will help you +do that (@pxref{Invoking guix refresh}). @item @cindex determinism, of build processes @@ -1574,16 +1535,17 @@ Teams [env]$ git send-email --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org -2 @end example -@node Tracking Bugs and Patches -@section Tracking Bugs and Patches +@node Tracking Bugs and Changes +@section Tracking Bugs and Changes -This section describes how the Guix project tracks its bug reports and -patch submissions. +This section describes how the Guix project tracks its bug reports, +patch submissions and topic branches. @menu -* The Issue Tracker:: The official bug and patch tracker. -* Debbugs User Interfaces:: Ways to interact with Debbugs. -* Debbugs Usertags:: Tag reports with custom labels. +* The Issue Tracker:: The official bug and patch tracker. +* Managing Patches and Branches:: How changes to Guix are managed. +* Debbugs User Interfaces:: Ways to interact with Debbugs. +* Debbugs Usertags:: Tag reports with custom labels. @end menu @node The Issue Tracker @@ -1600,6 +1562,51 @@ The Issue Tracker against the @code{guix-patches} package by sending email to @email{guix-patches@@gnu.org} (@pxref{Submitting Patches}). +@cindex branching strategy +@cindex rebuild scheduling strategy +@node Managing Patches and Branches +@subsection Managing Patches and Branches + +Changes should be posted to @email{guix-patches@@gnu.org}. This mailing +list fills the patch-tracking database (@pxref{The Issue Tracker}). It +also allows patches to be picked up and tested by the quality assurance +tooling; the result of that testing eventually shows up on the dashboard +at @indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where +@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave +time for a review, without committing anything. + +As an exception, some changes considered ``trivial'' or ``obvious'' may +be pushed directly to the @code{master} branch. This includes changes +to fix typos and reverting commits that caused immediate problems. This +is subject to being adjusted, allowing individuals to commit directly on +non-controversial changes on parts they’re familiar with. + +Changes which affect more than 300 dependent packages (@pxref{Invoking +guix refresh}) should first be pushed to a topic branch other than +@code{master}; the set of changes should be consistent---e.g., ``GNOME +update'', ``NumPy update'', etc. This allows for testing: the branch +will automatically show up at +@indicateurl{https://qa.guix.gnu.org/branch/@var{branch}}, with an +indication of its build status on various platforms. + +To help coordinate the merging of branches, you must create a new +guix-patches issue each time you wish to merge a branch (@pxref{The +Issue Tracker}). These issues indicate the order in which the branches +should be merged, so take a look at the open issues for merging branches +and mark the issue you create as @dfn{blocked} by the issue previously +at the back of the queue. + +Normally branches will be merged in a ``first come, first merged'' +manner, tracked through the guix-patches issues. If you agree on a +different order with those involved, you can track this by updating +which issues block which other issues. Therefore, to know which branch +is at the front of the queue, look for the issue which isn't +@dfn{blocked} by any other branch merges. + +Once a branch is at the front of the queue, wait until sufficient time +has passed for the build farms to have processed the changes, and for +the necessary testing to have happened. + @node Debbugs User Interfaces @subsection Debbugs User Interfaces @@ -1816,23 +1823,14 @@ Commit Access (discussions of the policy can take place on @email{guix-devel@@gnu.org}). -Changes should be posted to @email{guix-patches@@gnu.org}. This mailing -list fills the patch-tracking database (@pxref{Tracking Bugs and -Patches}). It also allows patches to be picked up and tested by the -quality assurance tooling; the result of that testing eventually shows -up on the dashboard at -@indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where -@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave -time for a review, without committing anything (@pxref{Submitting -Patches}). If you didn’t receive any reply after one week (two weeks -for more significant changes), and if you're confident, it's OK to -commit. +Ensure you're aware of how the changes should be handled +(@pxref{Managing Patches and Branches}) prior to being pushed to the +repository, especially for the @code{master} branch. -As an exception, some changes considered ``trivial'' or ``obvious'' may -be pushed directly. This includes changes to fix typos and reverting -commits that caused immediate problems. This is subject to being -adjusted, allowing individuals to commit directly on non-controversial -changes on parts they’re familiar with. +If you're committing and pushing your own changes, try and wait at least +one week (two weeks for more significant changes) after you send them +for review. After this, if no one else is available to review them and +if you're confident about the changes, it's OK to commit. When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., diff --git a/doc/guix.texi b/doc/guix.texi index 5fd2449ed5..f93778f358 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -636,18 +636,18 @@ GNU Distribution RYF Talos II mainboard}. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (@pxref{Substitutes}), and some packages may fail to -build (@pxref{Tracking Bugs and Patches}). That said, the Guix +build (@pxref{Tracking Bugs and Changes}). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved! @item riscv64-linux little-endian 64-bit RISC-V processors, specifically RV64GC, and -Linux-Libre kernel. This platform is available as a "technology preview": -although it is supported, substitutes are not yet available from the -build farm (@pxref{Substitutes}), and some packages may fail to build -(@pxref{Tracking Bugs and Patches}). That said, the Guix community is -actively working on improving this support, and now is a great time to -try it and get involved! +Linux-Libre kernel. This platform is available as a "technology +preview": although it is supported, substitutes are not yet available +from the build farm (@pxref{Substitutes}), and some packages may fail to +build (@pxref{Tracking Bugs and Changes}). That said, the Guix +community is actively working on improving this support, and now is a +great time to try it and get involved! @end table base-commit: 63e5975cac15102e35032d15fcd90e43d5610fa4 prerequisite-patch-id: 3576be703371d049aa43170dc47ec8285b8f739e -- 2.40.1 From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 31 May 2023 10:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 63459@debbugs.gnu.org Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16855273313328 (code B ref 63459); Wed, 31 May 2023 10:03:01 +0000 Received: (at 63459) by debbugs.gnu.org; 31 May 2023 10:02:11 +0000 Received: from localhost ([127.0.0.1]:34912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4Ief-0000ra-6G for submit@debbugs.gnu.org; Wed, 31 May 2023 06:02:10 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4Iea-0000rO-1q for 63459@debbugs.gnu.org; Wed, 31 May 2023 06:02:08 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id CA3D027BBE2; Wed, 31 May 2023 11:02:02 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 7a95ff1d; Wed, 31 May 2023 10:02:01 +0000 (UTC) References: <87y1lkzc98.fsf@gnu.org> <87pm6rlys0.fsf@cbaines.net> User-agent: mu4e 1.10.2; emacs 28.2 From: Christopher Baines Date: Wed, 31 May 2023 10:46:33 +0100 In-reply-to: <87pm6rlys0.fsf@cbaines.net> Message-ID: <87ilc8hl9k.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christopher Baines writes: > Ludovic Court=C3=A8s writes: > >> Hello, >> >> Thanks for this initiative! >> >> Christopher Baines skribis: >> >>> +order with those involved, you can track this by updating which issues >>> +block which other issues. Therefore, to know which branch is at the >>> +front of the queue, look for the issue which isn't blocked by any other >>> +branch merges. >>> + >>> +Once a branch is at the front of the queue, wait until sufficient time >>> +has passed for the build farms to have processed the changes, and for >>> +the necessary testing to have happened. >> >> This is a bit technical. How can I know =E2=80=9Cwhich branch is at the= front >> of the queue=E2=80=9D? Even as a seasoned Debbugs users, I=E2=80=99m no= t sure what I=E2=80=99m >> supposed to do here. Do you think we could provide ready to use >> commands (debbugs.el or =E2=80=98mumi=E2=80=99) or at least a sequence o= f steps to >> follow? > > So, I think there's two technical hurdles to overcome here. The first is > identifying the issues for merging branches, maybe for that we can set > out a format for the title of the bug, but I'm very open to > suggestions. Any way of identifying the open issues should be usable > through debbugs.el and mumi. > > The second hurdle is the queuing behaviour, which I think the blocking > behaviour is a natural fit for. Maybe the tooling is lacking but I think > that can be addressed. > > I want the qa-frontpage to display the queue of branches (and issues) in > a clear way, as well as providing links to make changes (as it does for > marking issues as moreinfo). I've sent a v2 now which makes more changes, most importantly it pulls the content out from the "Submitting Patches" section to it's own section, and also moves content from the Commit Policy in and references it. I've also made some progress with the qa-frontpage, it now shows a list of branches with the corresponding issues on the homepage. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmR3GxdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XcSJA//QCo+NnbzAziNr+oxhkN32GMIoRBHAFrb WQkAciikjFFRnL7wamIf5SdMPrgfOIAyfpwbD/XR5Lqxlv0TpngGlREsMxSi6fLS k70s81G1TXGaT798cEup3OPZcmEnPmgINpXO6YyUjwjjI5llIEYmekg/f7xTWDU6 qXeZDsaclLRIgj5qSct+x1A7u9Lx8AOKufJn9WVdDEqQxUnozTy7BNhGvaMkfWYB H5Z/MF5GrYdnUS3kycLgekkINZeC5QmvjOXSKRJMFIrmR4enj6WwxIGzdOr+c2b4 CfX9LqEjSXMXNZ1RebIV7g2L6BNOSjpgfxy4erzsYwu6KDIbfsm0tFnCQRzXTLwF 7DvMViB4ygJPOorVY/uknqFEQA72voUAkNUXwv6A6d5J64pt8Ad0iGiVnwqG8ziL bQ+89njv/bDyEZ/l0ieSZIvs/lxvbq/ZvgBLmM4970Bh1TafBgSI+J4JLc2e54Kh VkeuGA5s9Uct+O8MPL4GfbEgIA/wAm8Jz8e6RqmMcV8GOEXYWlItK9xXmGUXXG+5 rb+PXpLJQMBtcqACl9tw1JgrUiJ4Ce2ykGVhC3o+G7mgRH1Y/Zhgdg/e5TPkS2NY rJDWnZTYTsFcr9sl9Yoy2UPeB5shT9UQHiq02V3Fkedgt2ankyK1fUCUiUOcH66Z 5CiHKAjvb34= =5dFP -----END PGP SIGNATURE----- --=-=-=-- From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 06 Jun 2023 15:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Christopher Baines Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.168606525817199 (code B ref 63459); Tue, 06 Jun 2023 15:28:02 +0000 Received: (at 63459) by debbugs.gnu.org; 6 Jun 2023 15:27:38 +0000 Received: from localhost ([127.0.0.1]:52822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Yaw-0004TL-B4 for submit@debbugs.gnu.org; Tue, 06 Jun 2023 11:27:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Yau-0004T7-0R for 63459@debbugs.gnu.org; Tue, 06 Jun 2023 11:27:36 -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 1q6Yao-0004Rg-O8; Tue, 06 Jun 2023 11:27:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=X2/9kpntvKKYPiwUr5TV4AvZNk7fMX0a50rAXVmN6lc=; b=FPzGsjaI9TqBZbcgls6V CELzJdX3/k3QfnwZGyxcXKittyHvA5mlssDmvSSe4B+0qVseUl1GwnLDkjDCS56ava5K/jbxGGV1Q K4Hqsocr/8Nu5j+57poSUjgndmp5RsIXJmF6vCDV3bwKwlh7DSx4gxTKrcp0QDvG6KoHNHgUwtBr6 I7XePqnPQfpKaTBYaR0Um6BTm1H69Vs53nIMhFqAkgCAGJRTsstlMJ6veOhg9Rivw56ocni9m1jsH W1refZVAWiyUrZrCShQwTRicpX/glaNtyjIudlYBENNj1pFBeAlNViGAXCsNLKDFVFSoUIjUaBU0R 6JnGeX9p38pggA==; Received: from [193.50.110.155] (helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6Yao-0004Gc-BD; Tue, 06 Jun 2023 11:27:30 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <9e9b6e968ab3faa7281d064cdfc59ef32adcf689.1685526070.git.mail@cbaines.net> Date: Tue, 06 Jun 2023 17:27:28 +0200 In-Reply-To: <9e9b6e968ab3faa7281d064cdfc59ef32adcf689.1685526070.git.mail@cbaines.net> (Christopher Baines's message of "Wed, 31 May 2023 10:41:12 +0100") Message-ID: <87ilc07grj.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi, Christopher Baines skribis: > Move away from using staging and core-updates, and make the strategy > independant of branch names. > > Keep the 300 dependent threshold for changes to master, as I don't have a= ny > specific reason to change this. > > Most importantly, require using guix-patches issues to coordinate merging= of > the branches, as I think that'll address the key issues that have shown up > recently where it's been unclear which branch should be merged next. > > * doc/contributing.texi (Submitting Patches): Move the branching strategy= to a > new Managing Patches and Branches section. > (Managing Patches and Branches): New section. > (Commit Policy): Simplify through referencing the new Managing Patches and > Branches section. > > Signed-off-by: Christopher Baines Neat! Only minor comments from me: > +@cindex branching strategy > +@cindex rebuild scheduling strategy > +@node Managing Patches and Branches > +@subsection Managing Patches and Branches Index entries should come after the section heading. > +To help coordinate the merging of branches, you must create a new > +guix-patches issue each time you wish to merge a branch (@pxref{The > +Issue Tracker}). These issues indicate the order in which the branches > +should be merged, so take a look at the open issues for merging branches > +and mark the issue you create as @dfn{blocked} by the issue previously > +at the back of the queue. IMO we=E2=80=99re still missing a footnote explaining how to block an issue. > +which issues block which other issues. Therefore, to know which branch > +is at the front of the queue, look for the issue which isn't > +@dfn{blocked} by any other branch merges. No need for @dfn the second time. I think this could also benefit from concrete instructions (like =E2=80=9Cgo to this URL=E2=80=9D) or a cross-re= ference to the Debbugs User Guide or something. Anyway, nothing crucial: overall it LGTM! Thanks, Ludo=E2=80=99. From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH v3] doc: Move and rewrite the branching strategy. References: In-Reply-To: Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 08 Jun 2023 14:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 63459@debbugs.gnu.org Cc: Christopher Baines Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16862342305075 (code B ref 63459); Thu, 08 Jun 2023 14:24:02 +0000 Received: (at 63459) by debbugs.gnu.org; 8 Jun 2023 14:23:50 +0000 Received: from localhost ([127.0.0.1]:57168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7GYH-0001Jl-38 for submit@debbugs.gnu.org; Thu, 08 Jun 2023 10:23:50 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7GY0-0001JN-Um for 63459@debbugs.gnu.org; Thu, 08 Jun 2023 10:23:48 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id 839EE27BBE2; Thu, 8 Jun 2023 15:23:31 +0100 (BST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 6f50a1ca; Thu, 8 Jun 2023 14:23:29 +0000 (UTC) From: Christopher Baines Date: Thu, 8 Jun 2023 15:23:28 +0100 Message-Id: X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Move away from using staging and core-updates, and make the strategy independant of branch names. Keep the 300 dependent threshold for changes to master, as I don't have any specific reason to change this. Most importantly, require using guix-patches issues to coordinate merging of the branches, as I think that'll address the key issues that have shown up recently where it's been unclear which branch should be merged next. * doc/contributing.texi (Submitting Patches): Move the branching strategy to a new Managing Patches and Branches section. (Managing Patches and Branches): New section. (Commit Policy): Simplify through referencing the new Managing Patches and Branches section. Signed-off-by: Christopher Baines --- doc/contributing.texi | 144 +++++++++++++++++++++--------------------- doc/guix.texi | 14 ++-- 2 files changed, 80 insertions(+), 78 deletions(-) diff --git a/doc/contributing.texi b/doc/contributing.texi index f692872c04..1581aa96a1 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -26,7 +26,7 @@ Contributing * Packaging Guidelines:: Growing the distribution. * Coding Style:: Hygiene of the contributor. * Submitting Patches:: Share your work. -* Tracking Bugs and Patches:: Keeping it all organized. +* Tracking Bugs and Changes:: Keeping it all organized. * Commit Access:: Pushing to the official repository. * Updating the Guix Package:: Updating the Guix package definition. * Writing Documentation:: Improving documentation in GNU Guix. @@ -1161,11 +1161,11 @@ Submitting Patches at the section on commit access (@pxref{Commit Access}). This mailing list is backed by a Debbugs instance, which allows us to -keep track of submissions (@pxref{Tracking Bugs and Patches}). Each -message sent to that mailing list gets a new tracking number assigned; -people can then follow up on the submission by sending email to -@code{@var{ISSUE_NUMBER}@@debbugs.gnu.org}, where @var{ISSUE_NUMBER} is -the tracking number (@pxref{Sending a Patch Series}). +keep track of submissions (@pxref{Tracking Bugs and Changes}). +Each message sent to that mailing list gets a new tracking number +assigned; people can then follow up on the submission by sending email +to @code{@var{ISSUE_NUMBER}@@debbugs.gnu.org}, where @var{ISSUE_NUMBER} +is the tracking number (@pxref{Sending a Patch Series}). Please write commit logs in the ChangeLog format (@pxref{Change Logs,,, standards, GNU Coding Standards}); you can check the commit history for @@ -1257,48 +1257,9 @@ Submitting Patches the @code{texlive-tiny} package or @code{texlive-union} procedure instead. @item -For important changes, check that dependent packages (if applicable) are -not affected by the change; @code{guix refresh --list-dependent -@var{package}} will help you do that (@pxref{Invoking guix refresh}). - -@c See . -@cindex branching strategy -@cindex rebuild scheduling strategy -Depending on the number of dependent packages and thus the amount of -rebuilding induced, commits go to different branches, along these lines: - -@table @asis -@item 300 dependent packages or less -@code{master} branch (non-disruptive changes). - -@item between 300 and 1,800 dependent packages -@code{staging} branch (non-disruptive changes). This branch is intended -to be merged in @code{master} every 6 weeks or so. Topical changes -(e.g., an update of the GNOME stack) can instead go to a specific branch -(say, @code{gnome-updates}). This branch is not expected to be -buildable or usable until late in its development process. - -@item more than 1,800 dependent packages -@code{core-updates} branch (may include major and potentially disruptive -changes). This branch is intended to be merged in @code{master} every -6 months or so. This branch is not expected to be buildable or usable -until late in its development process. -@end table - -All these branches are @uref{https://@value{SUBSTITUTE-SERVER-1}, -tracked by our build farm} and merged into @code{master} once -everything has been successfully built. This allows us to fix issues -before they hit users, and to reduce the window during which pre-built -binaries are not available. - -When we decide to start building the @code{staging} or -@code{core-updates} branches, they will be forked and renamed with the -suffix @code{-frozen}, at which time only bug fixes may be pushed to the -frozen branches. The @code{core-updates} and @code{staging} branches -will remain open to accept patches for the next cycle. Please ask on -the mailing list or IRC if unsure where to place a patch. -@c TODO: It would be good with badges on the website that tracks these -@c branches. Or maybe even a status page. +Check that dependent packages (if applicable) are not affected by the +change; @code{guix refresh --list-dependent @var{package}} will help you +do that (@pxref{Invoking guix refresh}). @item @cindex determinism, of build processes @@ -1574,16 +1535,17 @@ Teams [env]$ git send-email --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org -2 @end example -@node Tracking Bugs and Patches -@section Tracking Bugs and Patches +@node Tracking Bugs and Changes +@section Tracking Bugs and Changes -This section describes how the Guix project tracks its bug reports and -patch submissions. +This section describes how the Guix project tracks its bug reports, +patch submissions and topic branches. @menu -* The Issue Tracker:: The official bug and patch tracker. -* Debbugs User Interfaces:: Ways to interact with Debbugs. -* Debbugs Usertags:: Tag reports with custom labels. +* The Issue Tracker:: The official bug and patch tracker. +* Managing Patches and Branches:: How changes to Guix are managed. +* Debbugs User Interfaces:: Ways to interact with Debbugs. +* Debbugs Usertags:: Tag reports with custom labels. @end menu @node The Issue Tracker @@ -1600,6 +1562,55 @@ The Issue Tracker against the @code{guix-patches} package by sending email to @email{guix-patches@@gnu.org} (@pxref{Submitting Patches}). +@node Managing Patches and Branches +@subsection Managing Patches and Branches +@cindex branching strategy +@cindex rebuild scheduling strategy + +Changes should be posted to @email{guix-patches@@gnu.org}. This mailing +list fills the patch-tracking database (@pxref{The Issue Tracker}). It +also allows patches to be picked up and tested by the quality assurance +tooling; the result of that testing eventually shows up on the dashboard +at @indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where +@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave +time for a review, without committing anything. + +As an exception, some changes considered ``trivial'' or ``obvious'' may +be pushed directly to the @code{master} branch. This includes changes +to fix typos and reverting commits that caused immediate problems. This +is subject to being adjusted, allowing individuals to commit directly on +non-controversial changes on parts they’re familiar with. + +Changes which affect more than 300 dependent packages (@pxref{Invoking +guix refresh}) should first be pushed to a topic branch other than +@code{master}; the set of changes should be consistent---e.g., ``GNOME +update'', ``NumPy update'', etc. This allows for testing: the branch +will automatically show up at +@indicateurl{https://qa.guix.gnu.org/branch/@var{branch}}, with an +indication of its build status on various platforms. + +To help coordinate the merging of branches, you must create a new +guix-patches issue each time you wish to merge a branch (@pxref{The +Issue Tracker}). These issues indicate the order in which the branches +should be merged, so take a look at the open issues for merging branches +and mark the issue you create as @dfn{blocked} by the issue previously +at the back of the queue@footnote{You can mark an issue as blocked by +another by emailing @email{control@@debbugs.gnu.org} with the following +line in the body of the email: @code{block XXXXX by YYYYY}. Where +@code{XXXXX} is the number for the blocked issue, and @code{YYYYY} is +the number for the issue blocking it.}. + +Normally branches will be merged in a ``first come, first merged'' +manner, tracked through the guix-patches issues. If you agree on a +different order with those involved, you can track this by updating +which issues block which other issues. Therefore, to know which branch +is at the front of the queue, look for the issue which isn't blocked by +any other branch merges. + +Once a branch is at the front of the queue, wait until sufficient time +has passed for the build farms to have processed the changes, and for +the necessary testing to have happened. + @node Debbugs User Interfaces @subsection Debbugs User Interfaces @@ -1816,23 +1827,14 @@ Commit Access (discussions of the policy can take place on @email{guix-devel@@gnu.org}). -Changes should be posted to @email{guix-patches@@gnu.org}. This mailing -list fills the patch-tracking database (@pxref{Tracking Bugs and -Patches}). It also allows patches to be picked up and tested by the -quality assurance tooling; the result of that testing eventually shows -up on the dashboard at -@indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where -@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave -time for a review, without committing anything (@pxref{Submitting -Patches}). If you didn’t receive any reply after one week (two weeks -for more significant changes), and if you're confident, it's OK to -commit. +Ensure you're aware of how the changes should be handled +(@pxref{Managing Patches and Branches}) prior to being pushed to the +repository, especially for the @code{master} branch. -As an exception, some changes considered ``trivial'' or ``obvious'' may -be pushed directly. This includes changes to fix typos and reverting -commits that caused immediate problems. This is subject to being -adjusted, allowing individuals to commit directly on non-controversial -changes on parts they’re familiar with. +If you're committing and pushing your own changes, try and wait at least +one week (two weeks for more significant changes) after you send them +for review. After this, if no one else is available to review them and +if you're confident about the changes, it's OK to commit. When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., diff --git a/doc/guix.texi b/doc/guix.texi index 01f4e0105f..83cbf004bb 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -637,18 +637,18 @@ GNU Distribution RYF Talos II mainboard}. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (@pxref{Substitutes}), and some packages may fail to -build (@pxref{Tracking Bugs and Patches}). That said, the Guix +build (@pxref{Tracking Bugs and Changes}). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved! @item riscv64-linux little-endian 64-bit RISC-V processors, specifically RV64GC, and -Linux-Libre kernel. This platform is available as a "technology preview": -although it is supported, substitutes are not yet available from the -build farm (@pxref{Substitutes}), and some packages may fail to build -(@pxref{Tracking Bugs and Patches}). That said, the Guix community is -actively working on improving this support, and now is a great time to -try it and get involved! +Linux-Libre kernel. This platform is available as a "technology +preview": although it is supported, substitutes are not yet available +from the build farm (@pxref{Substitutes}), and some packages may fail to +build (@pxref{Tracking Bugs and Changes}). That said, the Guix +community is actively working on improving this support, and now is a +great time to try it and get involved! @end table base-commit: 91454f54a4bf07030b51d718482416518ba5c9a7 prerequisite-patch-id: 0c60b9c48946553181183bd4a16611a27f6e62bf -- 2.40.1 From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] Changes to the branching/commit policy References: In-Reply-To: Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 08 Jun 2023 14:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: guix-devel@gnu.org Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16862348296106 (code B ref 63459); Thu, 08 Jun 2023 14:34:02 +0000 Received: (at 63459) by debbugs.gnu.org; 8 Jun 2023 14:33:49 +0000 Received: from localhost ([127.0.0.1]:57181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7Ghw-0001aP-RH for submit@debbugs.gnu.org; Thu, 08 Jun 2023 10:33:49 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7Ghv-0001aH-Dc for 63459@debbugs.gnu.org; Thu, 08 Jun 2023 10:33:48 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id 7058527BBE2; Thu, 8 Jun 2023 15:33:46 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 9423b404; Thu, 8 Jun 2023 14:33:45 +0000 (UTC) User-agent: mu4e 1.10.2; emacs 28.2 From: Christopher Baines Date: Thu, 08 Jun 2023 15:24:37 +0100 Message-ID: <87y1kuyqew.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hey! The changes in #63459 have strayed now in to touching the commit policy [1]. My intent was to simplify the guidance by grouping it better, but I think the significant change here is that the commit policy now references the entire branching strategy, rather than just talking about sending patches for review. 1: https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html#Commit-Policy That new branching strategy makes some "should" requirements on sending patches for review and pushing to topic branches for larger changes. It also makes a "must" requirement on opening guix-patches issues to track and manage merging branches. I'd like to merge these changes next week since they've been up for a few weeks, so do comment if you have any thoughts or if you'd like more time to review them. Thanks, Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmSB5sdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XfGxQ/9F32nutsez4pTXtM1A4vtk1LX1l4cdZcW MCw0FfY1I+E4+8K4NMLJJrrXAJqkbkZHxz2vCDDfdMEaEKZcpo+ZhN7kNEHBp/Fe rICz4wV37YCxzCFFWA6wuR9cqaziHHh3BFfwzFp6CNscRKcpqHV/6XZJ8hviG48h 3O51CQznGCwSY+6X2b3cSpPutPfCUrqJt8hfMCxxu4JVFZnuf38W12Ta1gUkz8hE km0YhED40e5eR4vgSxn0n/AM0M17WM+gnIzsCr9PkSQU0kOWBZIxUn0/F2eAdeMk bRVtAIjLqbkcY5fMxfSPYK0kGryFnpHvpPG/Men2CNL/RHaezE/TSUoDG4HomZd0 BELGJl9IDzX5t/JCCSkE6qmZeGq6xOzo3t7TOE7qy/aiWBQ2da6cWDzPz2wNDjM7 EJ9HRgrplsIq3ZdJT0olzVCbFmcLKetyk/+MvId5yf1izeNsotP7m7FzfqYc+2B1 /3o2Z04sSqYMuxls4q4t7onxl0SDAcpBWVpoG0iiHwHxgk/SaTiB2UvRPrv2s32y pmhqtwoM3REuPNgiZO7We75XWhU/fpUxCwJM1eBWRAvC2MypdZldCXD2gSppGqia NvZBgz8mjIB1/eUjH4GjXP3Vaa3f5dll9FNuSi0752fIsH53ECR7js8/i++sAdpb Mx4A82UOP70= =4jOA -----END PGP SIGNATURE----- --=-=-=-- From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] Changes to the branching/commit policy Resent-From: Andreas Enge Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 09 Jun 2023 10:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Christopher Baines Cc: guix-devel@gnu.org, 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16863054127724 (code B ref 63459); Fri, 09 Jun 2023 10:11:02 +0000 Received: (at 63459) by debbugs.gnu.org; 9 Jun 2023 10:10:12 +0000 Received: from localhost ([127.0.0.1]:58318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7Z4O-00020V-6M for submit@debbugs.gnu.org; Fri, 09 Jun 2023 06:10:12 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:45646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7Z4L-00020D-DB for 63459@debbugs.gnu.org; Fri, 09 Jun 2023 06:10:10 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id B99371B5B; Fri, 9 Jun 2023 12:10:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx4ZN0cwfVV4; Fri, 9 Jun 2023 12:10:03 +0200 (CEST) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id DED7E1F1; Fri, 9 Jun 2023 12:10:02 +0200 (CEST) Date: Fri, 9 Jun 2023 12:10:01 +0200 From: Andreas Enge Message-ID: References: <87y1kuyqew.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87y1kuyqew.fsf@cbaines.net> X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello Chris, thanks for taking up this issue! I agreed with Ludovic's comments, so things look good now for me. A very minor point: In the section on "trivial" changes, I would drop this sentence (which was already there before): "This is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with." The sentence is meaningless, as everything is all the time subject to being adjusted; and we do not have immediate plans to adjust it. Looking forward to the merge since it clarifies things and removes the staging and core-updates branches not only from our minds, but also the texts. Andreas From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] Changes to the branching/commit policy Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 11 Jun 2023 09:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Andreas Enge Cc: guix-devel@gnu.org, 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.168647697111686 (code B ref 63459); Sun, 11 Jun 2023 09:50:02 +0000 Received: (at 63459) by debbugs.gnu.org; 11 Jun 2023 09:49:31 +0000 Received: from localhost ([127.0.0.1]:36732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8HhS-00032Q-PO for submit@debbugs.gnu.org; Sun, 11 Jun 2023 05:49:31 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8HhQ-00032H-3E for 63459@debbugs.gnu.org; Sun, 11 Jun 2023 05:49:29 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id 4D74B27BBE2; Sun, 11 Jun 2023 10:49:27 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id b850b67c; Sun, 11 Jun 2023 09:49:26 +0000 (UTC) References: <87y1kuyqew.fsf@cbaines.net> User-agent: mu4e 1.10.2; emacs 28.2 From: Christopher Baines Date: Sun, 11 Jun 2023 10:37:14 +0100 In-reply-to: Message-ID: <87mt16xra3.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andreas Enge writes: > thanks for taking up this issue! I agreed with Ludovic's comments, so > things look good now for me. A very minor point: In the section on > "trivial" changes, I would drop this sentence (which was already there > before): > "This is subject to being adjusted, allowing individuals to commit direct= ly > on non-controversial changes on parts they=E2=80=99re familiar with." > The sentence is meaningless, as everything is all the time subject to bei= ng > adjusted; and we do not have immediate plans to adjust it. My reading of this line is that "adjusted" is probably not the right word to use, but I think the intent here is to talk about how currently it's accepted that people can and will push non-controversial changes on parts they=E2=80=99re familiar with directly to master. I'm not sure if others read this similarly. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmSFmKRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XeQkg/+MYKL7du7fiwcAWh3anyOQAmaW/TwXtZG qmiEoSicjpSMIjWv2KA4wUme0I2sS5c1xgeDCCAk8o+zkOrzoCN96hov9cx6DIM1 Yn8RrHE961E5Gm++TbUgR8bb/jQNjCEofYpKnHUxt2Hsoj1xehJoChRo+PXmWFQ1 ZH0kgBDiwpixCPbKNyVbJpu7dC0OiOiE+IVpVfFzkK215LwdU6lyleAxQ6EZ00cn rtp5pJe7osF28085MEpHbrtK3Ja+SlVKM+I2rymB9tifFtfda5PfaXIY2TLj7vNw 8igziB0AFYqQGcVHjf2z5kZPOVBeFLk2bZISZFOsCRD2Cu+krfYnxxcvFYu9AcW5 ISyyNVDjHLlGsD42jE38gUoqEAnerY1Utjl+Y4h3KEdot2BjsobqWNgXuVa5tqcA PR4E+BTCXdNBXp1chxjxPAUe2ua31aiRabuq+dyikPKQOfoNtkttanzvJJpk5n8n oRAi2+A1VLyuBykABDZptUnKweVi3dPCUNeP1U39vNxkL8vn7c40OdzJQQc7b5Nv UoVRhySNT+nYF6MVBm9/WZIunR0beEM+UqQy216+jO1kFZJPssxvWF+S0qwTYu+U GiNBt9Q013uXy4V2TrDwPZa6h9W6GTtlZkQZPPXJigO2/dwXuJIG81YahX3wTLHP wY/kdR34ptM= =DTbW -----END PGP SIGNATURE----- --=-=-=-- From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] Changes to the branching/commit policy Resent-From: Andreas Enge Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 11 Jun 2023 09:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Christopher Baines Cc: guix-devel@gnu.org, 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.168647723812093 (code B ref 63459); Sun, 11 Jun 2023 09:54:02 +0000 Received: (at 63459) by debbugs.gnu.org; 11 Jun 2023 09:53:58 +0000 Received: from localhost ([127.0.0.1]:36745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8Hlm-00038y-IF for submit@debbugs.gnu.org; Sun, 11 Jun 2023 05:53:58 -0400 Received: from hera.aquilenet.fr ([185.233.100.1]:58276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8Hlh-00038g-NW for 63459@debbugs.gnu.org; Sun, 11 Jun 2023 05:53:56 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id C08EB1326; Sun, 11 Jun 2023 11:53:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgxfj5A8YR8H; Sun, 11 Jun 2023 11:53:47 +0200 (CEST) Received: from jurong (unknown [IPv6:2001:861:c4:f2f0::c64]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 552A612FF; Sun, 11 Jun 2023 11:53:47 +0200 (CEST) Date: Sun, 11 Jun 2023 11:53:45 +0200 From: Andreas Enge Message-ID: References: <87y1kuyqew.fsf@cbaines.net> <87mt16xra3.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mt16xra3.fsf@cbaines.net> X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Am Sun, Jun 11, 2023 at 10:37:14AM +0100 schrieb Christopher Baines: > My reading of this line is that "adjusted" is probably not the right > word to use, but I think the intent here is to talk about how currently > it's accepted that people can and will push non-controversial changes on > parts they’re familiar with directly to master. I read it the other way round: Right now it is not accepted, but it might be adjusted to allow non-controversial changes in the future. Actually the concept of "non-controversial commits" is probably controversial in itself... Andreas From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] Changes to the branching/commit policy Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 12 Jun 2023 01:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Christopher Baines Cc: guix-devel@gnu.org, Andreas Enge , 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.168653332923083 (code B ref 63459); Mon, 12 Jun 2023 01:29:02 +0000 Received: (at 63459) by debbugs.gnu.org; 12 Jun 2023 01:28:49 +0000 Received: from localhost ([127.0.0.1]:37865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8WMS-00060F-P7 for submit@debbugs.gnu.org; Sun, 11 Jun 2023 21:28:49 -0400 Received: from mail-qk1-f171.google.com ([209.85.222.171]:46556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8WMQ-0005zz-OZ for 63459@debbugs.gnu.org; Sun, 11 Jun 2023 21:28:47 -0400 Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-75d461fde66so314843385a.1 for <63459@debbugs.gnu.org>; Sun, 11 Jun 2023 18:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686533320; x=1689125320; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to; bh=SF9l0hI41jdy9Cnr5Mj68kVmDpBqHTU9Uj1AyuxfQ6E=; b=m4BdcwIml3yuTZYo8mXrcoYzlVl2QAXs66B6YEgxPttcHnxDex/NgILDh9gwJx/142 eS/2FrP6iTz12xKn591KPmsCKqETK7RzHmV1Tt8Eldh9dBCgrWD8Xz8vzdLUsbUTZ2Ts v+Uy4h98RYmudT8/VaDnGh3Q7jnF8lkRxDD9m/p/dD435ia9MfIydaE3nLj+Rig/sfKS Kou6ltckIByszvLKDz09AE/OJVIQ4joJQelAEF1eu3KQNNrv3vroCZW779zqijvgByhi bKXcVDcsx5mjjFnWFbpgTtkrLAn6KN4ScjCsFcEVqpxa1sWn4q6vvGc68A9F23WlIsw/ WC+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686533320; x=1689125320; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SF9l0hI41jdy9Cnr5Mj68kVmDpBqHTU9Uj1AyuxfQ6E=; b=UvZ5UGiu2+37bcsaiLfeJHkNoqzuLNab2PcAgtoiZVVa7/cmpYG9NO+LDPcLQNtrsG PQqtbgfd+nsWb8y/KN48RBSNGmjkW6SJfu5LM9Z7uflT17w/paLgipho1pVASxqvXpbP 7shJSepGCGJ6Qh3kqnV7NlViBTAhaLKlDo49OfJV7IjcN1HbsC26K6L+D+Y7bw5oIFQT cam0172F0oeC6CxBubped5EqsU6y7QkxjWqOS7rZZq+IX66QIbEpYhcdi91PRq3hZLh5 bfX9KRxgDqG6JBCCF8N+OHFgKqPmoCgh+SrpeIOayshaAMsbFxN/J97vYMH/FEDF0ZXJ F/Lg== X-Gm-Message-State: AC+VfDxAHyMd7345s0bsqgBOtBRI5hc1UYAHdjW5I1jGM8cZ1V7wWfg+ 1nWAD+lq1WG1XVIrljN0lfE2tkCG6eTkTQ== X-Google-Smtp-Source: ACHHUZ6bsafp5mTmLwGzAvrEFEEbrekM0L6vVsoxW5LF9RfY9irCF/Dy/B5ho49IczeEtcFPeSvocg== X-Received: by 2002:a05:620a:2d8e:b0:75f:232:7188 with SMTP id tr14-20020a05620a2d8e00b0075f02327188mr5871650qkn.6.1686533320654; Sun, 11 Jun 2023 18:28:40 -0700 (PDT) Received: from hurd (dsl-205-236-230-101.b2b2c.ca. [205.236.230.101]) by smtp.gmail.com with ESMTPSA id d13-20020a05620a140d00b00751517fd46esm2537471qkj.26.2023.06.11.18.28.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Jun 2023 18:28:40 -0700 (PDT) From: Maxim Cournoyer References: <87y1kuyqew.fsf@cbaines.net> <87mt16xra3.fsf@cbaines.net> Date: Sun, 11 Jun 2023 21:28:38 -0400 In-Reply-To: <87mt16xra3.fsf@cbaines.net> (Christopher Baines's message of "Sun, 11 Jun 2023 10:37:14 +0100") Message-ID: <87pm618o55.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Christopher, Christopher Baines writes: > Andreas Enge writes: > >> thanks for taking up this issue! I agreed with Ludovic's comments, so >> things look good now for me. A very minor point: In the section on >> "trivial" changes, I would drop this sentence (which was already there >> before): >> "This is subject to being adjusted, allowing individuals to commit direc= tly >> on non-controversial changes on parts they=E2=80=99re familiar with." >> The sentence is meaningless, as everything is all the time subject to be= ing >> adjusted; and we do not have immediate plans to adjust it. > > My reading of this line is that "adjusted" is probably not the right > word to use, but I think the intent here is to talk about how currently > it's accepted that people can and will push non-controversial changes on > parts they=E2=80=99re familiar with directly to master. > > I'm not sure if others read this similarly. That's how I read it as well. I like the ability for people to, at times depending on the situation, choose to push directly to fix or update something instead of going through the otherwise recommended 1 week QA/review flow. --=20 Thanks, Maxim From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 12 Jun 2023 02:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Christopher Baines Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.168653748430497 (code B ref 63459); Mon, 12 Jun 2023 02:39:01 +0000 Received: (at 63459) by debbugs.gnu.org; 12 Jun 2023 02:38:04 +0000 Received: from localhost ([127.0.0.1]:38253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8XRU-0007vo-1l for submit@debbugs.gnu.org; Sun, 11 Jun 2023 22:38:04 -0400 Received: from mail-qk1-f175.google.com ([209.85.222.175]:62757) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8XRS-0007vG-2d for 63459@debbugs.gnu.org; Sun, 11 Jun 2023 22:38:03 -0400 Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-7606e639083so45488785a.1 for <63459@debbugs.gnu.org>; Sun, 11 Jun 2023 19:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686537476; x=1689129476; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=Qw+VQVpob0MQHzU/pvvwkgf9n9J9tFMOnFJtFN/BhR0=; b=kcJfA+MY60OuvXs6jsuGy3yrwcBuO9YElycwI+ZLc+hhnGjcaRjuTDQf3l/o4J0HKC i8v6rbrHQOuyvd2HIO21tFV7hMufH2lc/8PPsriXbLvwnTZp/KmQ0pabMGfyUqJ9ux1W 4e8zuZ2NFwulBNmCGux8zlEqSLgy0BOr0UhCYdBdqJ58ZWQEClFLvfa0YOP6bmXVLsW6 xtxCjWw5HOOIGq5lqNbSfT1CBLr8Rq4riKe4FLMWx5HxHT/KFuGylo+WfzXMuBCOKzn1 38VhrTcnHKXMp7D9NN+rXhSBLqqvreBork8M2m1HHCrtUEP1D3k+yv1TnD5Py+hz/1Y0 dISQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686537476; x=1689129476; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Qw+VQVpob0MQHzU/pvvwkgf9n9J9tFMOnFJtFN/BhR0=; b=VXQvEyXSRUooiqYk1XVVvWYUp7J0zByvqR5C/iveTjfNievL8BlfnvbEvl1b17uEge C5NdtPna5BRxOfyaxNobz+Ld7mTonCPwOjgocpYYnsrFYtbBjy9iFC7OGMlyPDbpra5Z ZqNyKlut2YWc9hbBXG1sbdN/l7A50Lb1jT7yat6tVoK2phK90lmExu2IxTk5wZmaJZ8K tPPp01qqILFy6P+9+xFZETxr2EZwzj2F7DRtecrLiJ7LdQWddkn77/+Kzg58rLeLE6Gh H15SavgjFsA77NDQhEH5UHf16SHGB86kOQPYs1mLfo6qK3bNwYYZz7fU1mVt1Vfmv8M5 pUDw== X-Gm-Message-State: AC+VfDzusH79hq+LeEZZEW0IKmavYNiEXkHmnJDgByOyOkCq4b1vshOE eWO/nxDlNYSdYSf59m1ak0PZTWVPJd4Z0g== X-Google-Smtp-Source: ACHHUZ7EH6A6KqwkZOxYpeQz9tTtvQHYLWjMpqQsF1GbfBQ8R/hxtWmyPsLqUC+pOVoIKMWTLCg65g== X-Received: by 2002:a05:620a:3b12:b0:75e:ca48:51c8 with SMTP id tl18-20020a05620a3b1200b0075eca4851c8mr11924662qkn.4.1686537475779; Sun, 11 Jun 2023 19:37:55 -0700 (PDT) Received: from hurd (dsl-205-236-230-101.b2b2c.ca. [205.236.230.101]) by smtp.gmail.com with ESMTPSA id m16-20020ae9e710000000b007592174cb08sm2587570qka.10.2023.06.11.19.37.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Jun 2023 19:37:55 -0700 (PDT) From: Maxim Cournoyer References: Date: Sun, 11 Jun 2023 22:37:53 -0400 In-Reply-To: (Christopher Baines's message of "Thu, 8 Jun 2023 15:23:28 +0100") Message-ID: <878rcp8kxq.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Christopher, Christopher Baines writes: > Move away from using staging and core-updates, and make the strategy > independant of branch names. > > Keep the 300 dependent threshold for changes to master, as I don't have any > specific reason to change this. > > Most importantly, require using guix-patches issues to coordinate merging of > the branches, as I think that'll address the key issues that have shown up > recently where it's been unclear which branch should be merged next. > > * doc/contributing.texi (Submitting Patches): Move the branching strategy to a > new Managing Patches and Branches section. > (Managing Patches and Branches): New section. > (Commit Policy): Simplify through referencing the new Managing Patches and > Branches section. [...] > + > +To help coordinate the merging of branches, you must create a new > +guix-patches issue each time you wish to merge a branch (@pxref{The > +Issue Tracker}). These issues indicate the order in which the branches > +should be merged, so take a look at the open issues for merging branches > +and mark the issue you create as @dfn{blocked} by the issue previously > +at the back of the queue@footnote{You can mark an issue as blocked by > +another by emailing @email{control@@debbugs.gnu.org} with the following > +line in the body of the email: @code{block XXXXX by YYYYY}. Where > +@code{XXXXX} is the number for the blocked issue, and @code{YYYYY} is > +the number for the issue blocking it.}. Maybe by default, since the strategy would be "first come, first merged", we can forego with the 'block' tags, as issues will already be posted in the order (and given an increasing number) they should be merged? Then the nitty-gritty details of micro-managing block tags can be mentioned only when they are useful, e.g. ... > +Normally branches will be merged in a ``first come, first merged'' > +manner, tracked through the guix-patches issues. If you agree on a > +different order with those involved, you can track this by updating > +which issues block which other issues. Therefore, to know which branch > +is at the front of the queue, look for the issue which isn't blocked by > +any other branch merges. ... here. Can anyone merge the branches of someone else that posted them to the tracker but 'hasn't gotten around' to merge them to the repo (e.g. gone on vacation), although they were fully QA'd, blocking every other branch merge? > +Once a branch is at the front of the queue, wait until sufficient time > +has passed for the build farms to have processed the changes, and for > +the necessary testing to have happened. What does that mean concretely? How can I track the build status of a change? Please at least mention the QA badge which is visible from issues.guix.gnu.org and perhaps other tricks I'm unaware of :-). Thanks for working on completing the documentation of the new work flow. -- Maxim From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH v4] doc: Move and rewrite the branching strategy. References: In-Reply-To: Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 12 Jun 2023 09:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 63459@debbugs.gnu.org Cc: Christopher Baines Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16865604815534 (code B ref 63459); Mon, 12 Jun 2023 09:02:02 +0000 Received: (at 63459) by debbugs.gnu.org; 12 Jun 2023 09:01:21 +0000 Received: from localhost ([127.0.0.1]:38826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8dQO-0001RA-Hd for submit@debbugs.gnu.org; Mon, 12 Jun 2023 05:01:21 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8dQM-0001Qz-0E for 63459@debbugs.gnu.org; Mon, 12 Jun 2023 05:01:19 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id A294E27BBE2; Mon, 12 Jun 2023 10:01:16 +0100 (BST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 083ce685; Mon, 12 Jun 2023 09:01:14 +0000 (UTC) From: Christopher Baines Date: Mon, 12 Jun 2023 10:01:14 +0100 Message-Id: <17bfa67fe13343dd5929de85494fca59a4766637.1686560473.git.mail@cbaines.net> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Move away from using staging and core-updates, and make the strategy independant of branch names. Keep the 300 dependent threshold for changes to master, as I don't have any specific reason to change this. Most importantly, require using guix-patches issues to coordinate merging of the branches, as I think that'll address the key issues that have shown up recently where it's been unclear which branch should be merged next. * doc/contributing.texi (Submitting Patches): Move the branching strategy to a new Managing Patches and Branches section. (Managing Patches and Branches): New section. (Commit Policy): Simplify through referencing the new Managing Patches and Branches section. Signed-off-by: Christopher Baines --- doc/contributing.texi | 144 +++++++++++++++++++++--------------------- doc/guix.texi | 14 ++-- 2 files changed, 80 insertions(+), 78 deletions(-) diff --git a/doc/contributing.texi b/doc/contributing.texi index 958fc44cbd..3a402c13a9 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -26,7 +26,7 @@ Contributing * Packaging Guidelines:: Growing the distribution. * Coding Style:: Hygiene of the contributor. * Submitting Patches:: Share your work. -* Tracking Bugs and Patches:: Keeping it all organized. +* Tracking Bugs and Changes:: Keeping it all organized. * Commit Access:: Pushing to the official repository. * Updating the Guix Package:: Updating the Guix package definition. * Writing Documentation:: Improving documentation in GNU Guix. @@ -1161,11 +1161,11 @@ Submitting Patches at the section on commit access (@pxref{Commit Access}). This mailing list is backed by a Debbugs instance, which allows us to -keep track of submissions (@pxref{Tracking Bugs and Patches}). Each -message sent to that mailing list gets a new tracking number assigned; -people can then follow up on the submission by sending email to -@code{@var{ISSUE_NUMBER}@@debbugs.gnu.org}, where @var{ISSUE_NUMBER} is -the tracking number (@pxref{Sending a Patch Series}). +keep track of submissions (@pxref{Tracking Bugs and Changes}). +Each message sent to that mailing list gets a new tracking number +assigned; people can then follow up on the submission by sending email +to @code{@var{ISSUE_NUMBER}@@debbugs.gnu.org}, where @var{ISSUE_NUMBER} +is the tracking number (@pxref{Sending a Patch Series}). Please write commit logs in the ChangeLog format (@pxref{Change Logs,,, standards, GNU Coding Standards}); you can check the commit history for @@ -1257,48 +1257,9 @@ Submitting Patches the @code{texlive-tiny} package or @code{texlive-union} procedure instead. @item -For important changes, check that dependent packages (if applicable) are -not affected by the change; @code{guix refresh --list-dependent -@var{package}} will help you do that (@pxref{Invoking guix refresh}). - -@c See . -@cindex branching strategy -@cindex rebuild scheduling strategy -Depending on the number of dependent packages and thus the amount of -rebuilding induced, commits go to different branches, along these lines: - -@table @asis -@item 300 dependent packages or less -@code{master} branch (non-disruptive changes). - -@item between 300 and 1,800 dependent packages -@code{staging} branch (non-disruptive changes). This branch is intended -to be merged in @code{master} every 6 weeks or so. Topical changes -(e.g., an update of the GNOME stack) can instead go to a specific branch -(say, @code{gnome-updates}). This branch is not expected to be -buildable or usable until late in its development process. - -@item more than 1,800 dependent packages -@code{core-updates} branch (may include major and potentially disruptive -changes). This branch is intended to be merged in @code{master} every -6 months or so. This branch is not expected to be buildable or usable -until late in its development process. -@end table - -All these branches are @uref{https://@value{SUBSTITUTE-SERVER-1}, -tracked by our build farm} and merged into @code{master} once -everything has been successfully built. This allows us to fix issues -before they hit users, and to reduce the window during which pre-built -binaries are not available. - -When we decide to start building the @code{staging} or -@code{core-updates} branches, they will be forked and renamed with the -suffix @code{-frozen}, at which time only bug fixes may be pushed to the -frozen branches. The @code{core-updates} and @code{staging} branches -will remain open to accept patches for the next cycle. Please ask on -the mailing list or IRC if unsure where to place a patch. -@c TODO: It would be good with badges on the website that tracks these -@c branches. Or maybe even a status page. +Check that dependent packages (if applicable) are not affected by the +change; @code{guix refresh --list-dependent @var{package}} will help you +do that (@pxref{Invoking guix refresh}). @item @cindex determinism, of build processes @@ -1574,16 +1535,17 @@ Teams [env]$ git send-email --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org -2 @end example -@node Tracking Bugs and Patches -@section Tracking Bugs and Patches +@node Tracking Bugs and Changes +@section Tracking Bugs and Changes -This section describes how the Guix project tracks its bug reports and -patch submissions. +This section describes how the Guix project tracks its bug reports, +patch submissions and topic branches. @menu -* The Issue Tracker:: The official bug and patch tracker. -* Debbugs User Interfaces:: Ways to interact with Debbugs. -* Debbugs Usertags:: Tag reports with custom labels. +* The Issue Tracker:: The official bug and patch tracker. +* Managing Patches and Branches:: How changes to Guix are managed. +* Debbugs User Interfaces:: Ways to interact with Debbugs. +* Debbugs Usertags:: Tag reports with custom labels. @end menu @node The Issue Tracker @@ -1600,6 +1562,55 @@ The Issue Tracker against the @code{guix-patches} package by sending email to @email{guix-patches@@gnu.org} (@pxref{Submitting Patches}). +@node Managing Patches and Branches +@subsection Managing Patches and Branches +@cindex branching strategy +@cindex rebuild scheduling strategy + +Changes should be posted to @email{guix-patches@@gnu.org}. This mailing +list fills the patch-tracking database (@pxref{The Issue Tracker}). It +also allows patches to be picked up and tested by the quality assurance +tooling; the result of that testing eventually shows up on the dashboard +at @indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where +@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave +time for a review, without committing anything. + +As an exception, some changes considered ``trivial'' or ``obvious'' may +be pushed directly to the @code{master} branch. This includes changes +to fix typos and reverting commits that caused immediate problems. This +is subject to being adjusted, allowing individuals to commit directly on +non-controversial changes on parts they’re familiar with. + +Changes which affect more than 300 dependent packages (@pxref{Invoking +guix refresh}) should first be pushed to a topic branch other than +@code{master}; the set of changes should be consistent---e.g., ``GNOME +update'', ``NumPy update'', etc. This allows for testing: the branch +will automatically show up at +@indicateurl{https://qa.guix.gnu.org/branch/@var{branch}}, with an +indication of its build status on various platforms. + +To help coordinate the merging of branches, you must create a new +guix-patches issue each time you wish to merge a branch (@pxref{The +Issue Tracker}). Normally branches will be merged in a ``first come, +first merged'' manner, tracked through the guix-patches issues. + +If you agree on a different order with those involved, you can track +this by updating which issues block@footnote{You can mark an issue as +blocked by another by emailing @email{control@@debbugs.gnu.org} with the +following line in the body of the email: @code{block XXXXX by YYYYY}. +Where @code{XXXXX} is the number for the blocked issue, and @code{YYYYY} +is the number for the issue blocking it.} which other issues. +Therefore, to know which branch is at the front of the queue, look for +the oldest issue, or the issue that isn't @dfn{blocked} by any other +branch merges. An ordered list of branches with the open issues is +available at @url{https://qa.guix.gnu.org}. + +Once a branch is at the front of the queue, wait until sufficient time +has passed for the build farms to have processed the changes, and for +the necessary testing to have happened. For example, you can check +@indicateurl{https://qa.guix.gnu.org/branch/@var{branch}} to see +information on some builds and substitute availability. + @node Debbugs User Interfaces @subsection Debbugs User Interfaces @@ -1816,23 +1827,14 @@ Commit Access (discussions of the policy can take place on @email{guix-devel@@gnu.org}). -Changes should be posted to @email{guix-patches@@gnu.org}. This mailing -list fills the patch-tracking database (@pxref{Tracking Bugs and -Patches}). It also allows patches to be picked up and tested by the -quality assurance tooling; the result of that testing eventually shows -up on the dashboard at -@indicateurl{https://qa.guix.gnu.org/issue/@var{ISSUE_NUMBER}}, where -@var{ISSUE_NUMBER} is the number assigned by the issue tracker. Leave -time for a review, without committing anything (@pxref{Submitting -Patches}). If you didn’t receive any reply after one week (two weeks -for more significant changes), and if you're confident, it's OK to -commit. +Ensure you're aware of how the changes should be handled +(@pxref{Managing Patches and Branches}) prior to being pushed to the +repository, especially for the @code{master} branch. -As an exception, some changes considered ``trivial'' or ``obvious'' may -be pushed directly. This includes changes to fix typos and reverting -commits that caused immediate problems. This is subject to being -adjusted, allowing individuals to commit directly on non-controversial -changes on parts they’re familiar with. +If you're committing and pushing your own changes, try and wait at least +one week (two weeks for more significant changes) after you send them +for review. After this, if no one else is available to review them and +if you're confident about the changes, it's OK to commit. When pushing a commit on behalf of somebody else, please add a @code{Signed-off-by} line at the end of the commit log message---e.g., diff --git a/doc/guix.texi b/doc/guix.texi index 395fc25818..43dffe08c1 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -637,18 +637,18 @@ GNU Distribution RYF Talos II mainboard}. This platform is available as a "technology preview": although it is supported, substitutes are not yet available from the build farm (@pxref{Substitutes}), and some packages may fail to -build (@pxref{Tracking Bugs and Patches}). That said, the Guix +build (@pxref{Tracking Bugs and Changes}). That said, the Guix community is actively working on improving this support, and now is a great time to try it and get involved! @item riscv64-linux little-endian 64-bit RISC-V processors, specifically RV64GC, and -Linux-Libre kernel. This platform is available as a "technology preview": -although it is supported, substitutes are not yet available from the -build farm (@pxref{Substitutes}), and some packages may fail to build -(@pxref{Tracking Bugs and Patches}). That said, the Guix community is -actively working on improving this support, and now is a great time to -try it and get involved! +Linux-Libre kernel. This platform is available as a "technology +preview": although it is supported, substitutes are not yet available +from the build farm (@pxref{Substitutes}), and some packages may fail to +build (@pxref{Tracking Bugs and Changes}). That said, the Guix +community is actively working on improving this support, and now is a +great time to try it and get involved! @end table base-commit: 259b2e99e7121f05011742955636ff2dd96bf0e8 prerequisite-patch-id: 7a63d38dea972d66bf29acadde23be7e5d8b1b30 -- 2.40.1 From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 12 Jun 2023 09:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxim Cournoyer Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16865610836461 (code B ref 63459); Mon, 12 Jun 2023 09:12:02 +0000 Received: (at 63459) by debbugs.gnu.org; 12 Jun 2023 09:11:23 +0000 Received: from localhost ([127.0.0.1]:38831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8da6-0001g9-Jm for submit@debbugs.gnu.org; Mon, 12 Jun 2023 05:11:23 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8da3-0001g0-Tu for 63459@debbugs.gnu.org; Mon, 12 Jun 2023 05:11:20 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id 2D1F427BBE2; Mon, 12 Jun 2023 10:11:19 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id f1d36967; Mon, 12 Jun 2023 09:11:18 +0000 (UTC) References: <878rcp8kxq.fsf_-_@gmail.com> User-agent: mu4e 1.10.2; emacs 28.2 From: Christopher Baines Date: Mon, 12 Jun 2023 10:01:21 +0100 In-reply-to: <878rcp8kxq.fsf_-_@gmail.com> Message-ID: <87edmhxcy3.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Maxim Cournoyer writes: > Hi Christopher, > > Christopher Baines writes: > >> Move away from using staging and core-updates, and make the strategy >> independant of branch names. >> >> Keep the 300 dependent threshold for changes to master, as I don't have any >> specific reason to change this. >> >> Most importantly, require using guix-patches issues to coordinate merging of >> the branches, as I think that'll address the key issues that have shown up >> recently where it's been unclear which branch should be merged next. >> >> * doc/contributing.texi (Submitting Patches): Move the branching strategy to a >> new Managing Patches and Branches section. >> (Managing Patches and Branches): New section. >> (Commit Policy): Simplify through referencing the new Managing Patches and >> Branches section. > > [...] > >> + >> +To help coordinate the merging of branches, you must create a new >> +guix-patches issue each time you wish to merge a branch (@pxref{The >> +Issue Tracker}). These issues indicate the order in which the branches >> +should be merged, so take a look at the open issues for merging branches >> +and mark the issue you create as @dfn{blocked} by the issue previously >> +at the back of the queue@footnote{You can mark an issue as blocked by >> +another by emailing @email{control@@debbugs.gnu.org} with the following >> +line in the body of the email: @code{block XXXXX by YYYYY}. Where >> +@code{XXXXX} is the number for the blocked issue, and @code{YYYYY} is >> +the number for the issue blocking it.}. > > Maybe by default, since the strategy would be "first come, first > merged", we can forego with the 'block' tags, as issues will already be > posted in the order (and given an increasing number) they should be > merged? Then the nitty-gritty details of micro-managing block tags can > be mentioned only when they are useful, e.g. ... That sounds fine to me. >> +Normally branches will be merged in a ``first come, first merged'' >> +manner, tracked through the guix-patches issues. If you agree on a >> +different order with those involved, you can track this by updating >> +which issues block which other issues. Therefore, to know which branch >> +is at the front of the queue, look for the issue which isn't blocked by >> +any other branch merges. > > ... here. Can anyone merge the branches of someone else that posted > them to the tracker but 'hasn't gotten around' to merge them to the repo > (e.g. gone on vacation), although they were fully QA'd, blocking every > other branch merge? I've moved the blocking stuff down. As for the merging of branches that others have pushed, I'm not sure there's consensus regarding this. Personally I would like to see this, being able to merge other committers changes, I raised it on guix-devel recently [1]. 1: https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00263.html >> +Once a branch is at the front of the queue, wait until sufficient time >> +has passed for the build farms to have processed the changes, and for >> +the necessary testing to have happened. > > What does that mean concretely? How can I track the build status of a > change? Please at least mention the QA badge which is visible from > issues.guix.gnu.org and perhaps other tricks I'm unaware of :-). It's intentionally quite high level and non-concrete. Maybe we'll get to the point in the future where we have more specific requirements to meet before merging a branch, but I don't think we have that yet. qa.guix.gnu.org/branch/NAME is linked to above, and I've added another link to it here. The QA badge currently doesn't work for branches, but I'd like to get it working. I've sent a v4 now, thanks for taking a look! Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmSG4TRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XceNRAAiERY1duZQsVNqI4xJXRsMWfVob5GNv+2 BORmjgENto1ZHwUpZOIPi/8FrVk4RzdfNSOQl+7QNIXPD1p7jQkRtDyc0RPRalNA OD7vB2Qruk4FI0HEdl0zKKT114DcBe9KKAZcBM8nVnvB1twnviAfVC2ZrkJYYRx0 TYN2tAF0aINN19pbzUMVqj5mFZQMgHP1/84FTdoRqd/c8McLn2YXR7cYSq2+XzpR l+JJ1DXF5O7pkzCxCpr7gHFHrMqXR3KoyWXvNW8SglEM7lAJH50BooDgdw16EDoa rIxwCSbYNwSbBtwQqWjdUDNr4vtRLDNKBeawwQBWvspa3WB+vd08OSYYK1pt5xLc F2uN2k8aTqiP8IdV3jjsB85+pzwx/j58MVnK0s9WXy63+jx2M0FXWk+QHlLnEnZ4 6iweuVzr28sDmX1sHCUgujVkjhRzhRIeVXyFKQMzWKCCkemUteBF8XjJY778z3qo ZhYX8pHBchvT8yxet0cE/lTcwqBtVoOwIsdbtSa2DrgdMfabWY+k9hszU3M28vHh st3dB2e/wgC5pFJlS7PEPdlc3JERBrOXNOYiK4FgmNZ+JZxy1V38yQcg6x6zwWxo +1fbK2/uyUoDJsn/uavl5xv8C2uMYMA75+02ByF1ojhNUNS8bLZwi1Z25/kBBte5 MiQpR7P8Zkc= =VIOg -----END PGP SIGNATURE----- --=-=-=-- From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 12 Jun 2023 12:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Christopher Baines Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.16865724374410 (code B ref 63459); Mon, 12 Jun 2023 12:21:01 +0000 Received: (at 63459) by debbugs.gnu.org; 12 Jun 2023 12:20:37 +0000 Received: from localhost ([127.0.0.1]:39141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8gXF-000193-Ac for submit@debbugs.gnu.org; Mon, 12 Jun 2023 08:20:37 -0400 Received: from mail-vk1-f169.google.com ([209.85.221.169]:53495) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8gXD-00018n-Fc for 63459@debbugs.gnu.org; Mon, 12 Jun 2023 08:20:35 -0400 Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-4639f65a2f0so1128375e0c.2 for <63459@debbugs.gnu.org>; Mon, 12 Jun 2023 05:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686572429; x=1689164429; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=VwL9jHaN5B0xX4ZpE4AiH7Zs43YY7ciYBnu4U7k5Tx0=; b=qex2n9/55wk9aziSglvJVNCs7SrvaO4svQ1/T0U1ESpD1diEJnDP1JtOM/jXeIrLho IrqbO7zTVxMnO/Dxmz+ChFgltE6m2oK5IKaplN+8+QpWfumnAFHsJ0xiN8v88is6Fnfb V09cjdX+CSvmFIpgZaXScqqpQ/YzyDEXPvGPtjwKzep5AfSRpVf91XkKjc9Oac2HVwZZ PJzR2PjCZzpVhSTWTvwZEzC7xeq9Y5Vtus/HnnalLCbMIbH2TQRDUJDChY5AUVwv8jzV LuH/Az+cFWP1+fm4oIaQpt4LJYwXRcFIbWyYDSjZQstQ4Mav/P0pkjuBsnaQCc0hbuDr fulQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686572429; x=1689164429; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=VwL9jHaN5B0xX4ZpE4AiH7Zs43YY7ciYBnu4U7k5Tx0=; b=eUwuMVKIgAOSuu/sxYVcADUKfNR9x34BSmbLvDOLGuYiSi5EYXpshmILpFkmg8LvJB pmj4b2u7BRtvxIB8b/dsFmGI//Xx2gWIkJkf+f8jcrQEgOKEuJjTBBYmFDh9Ir37WnxH 04JiIsNHgIn3IkZepsVzEIiGG4lRyVaH5Irmy2K0yNKTjmmkIxNmMzADKBVxEOOZci0p iv/B5Y6yA/HxyBWdCThapRn4WNFe9a8w/GnjOIdYvn7BTMDjtqHayjVLpRUIxlTFcZKj sfAm4b6pgDTTVBJFkusep4Vw/Z9fApWfOggtG2yJFKR7yQ5P4n2irl6I4tg4EQcjlutP hCcg== X-Gm-Message-State: AC+VfDzhmwoYtMaSxXOF4IBlKVIj8HqFr499gi/sv7W3K3dbwJkbifeU 6RSFdlnlyuvYKid6uJ9HnqNTITbk4WlFuw== X-Google-Smtp-Source: ACHHUZ50EtZtkB1VNvFKCfCPFmLHoZTeXvp3Q8X5ldp40DU1iejOhdfjbw2pyzqUqBl74d4lz2DOxA== X-Received: by 2002:a1f:4389:0:b0:45f:9a8f:bc06 with SMTP id q131-20020a1f4389000000b0045f9a8fbc06mr3926960vka.10.1686572429355; Mon, 12 Jun 2023 05:20:29 -0700 (PDT) Received: from hurd (dsl-151-174.b2b2c.ca. [66.158.151.174]) by smtp.gmail.com with ESMTPSA id t18-20020a0cde12000000b0062142017f4csm433834qvk.143.2023.06.12.05.20.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jun 2023 05:20:28 -0700 (PDT) From: Maxim Cournoyer References: <878rcp8kxq.fsf_-_@gmail.com> <87edmhxcy3.fsf@cbaines.net> Date: Mon, 12 Jun 2023 08:20:27 -0400 In-Reply-To: <87edmhxcy3.fsf@cbaines.net> (Christopher Baines's message of "Mon, 12 Jun 2023 10:01:21 +0100") Message-ID: <874jnc98j8.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Chris, [...] >>> +To help coordinate the merging of branches, you must create a new >>> +guix-patches issue each time you wish to merge a branch (@pxref{The >>> +Issue Tracker}). These issues indicate the order in which the branches >>> +should be merged, so take a look at the open issues for merging branches >>> +and mark the issue you create as @dfn{blocked} by the issue previously >>> +at the back of the queue@footnote{You can mark an issue as blocked by >>> +another by emailing @email{control@@debbugs.gnu.org} with the following >>> +line in the body of the email: @code{block XXXXX by YYYYY}. Where >>> +@code{XXXXX} is the number for the blocked issue, and @code{YYYYY} is >>> +the number for the issue blocking it.}. >> >> Maybe by default, since the strategy would be "first come, first >> merged", we can forego with the 'block' tags, as issues will already be >> posted in the order (and given an increasing number) they should be >> merged? Then the nitty-gritty details of micro-managing block tags can >> be mentioned only when they are useful, e.g. ... > > That sounds fine to me. One disadvantage of this is that people must now manually find the preceding merge requests on the tracker; but if we have some convention prefix in the subject, e.g. 'MERGE' or similar (it's always implied we merge to master branch and nowhere else, correct?), that would still make it easy. When the tooling (build coordinator) offers a web view of the branches to be merged that can be linked as well. So I think it's a LGTM. -- Thanks, Maxim From unknown Thu Sep 11 13:39:44 2025 X-Loop: help-debbugs@gnu.org Subject: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Resent-From: Christopher Baines Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 12 Jun 2023 19:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63459 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Maxim Cournoyer Cc: 63459@debbugs.gnu.org Received: via spool by 63459-submit@debbugs.gnu.org id=B63459.168659992031266 (code B ref 63459); Mon, 12 Jun 2023 19:59:02 +0000 Received: (at 63459) by debbugs.gnu.org; 12 Jun 2023 19:58:40 +0000 Received: from localhost ([127.0.0.1]:40726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8ngW-00088D-9C for submit@debbugs.gnu.org; Mon, 12 Jun 2023 15:58:40 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8ngT-000884-OE for 63459@debbugs.gnu.org; Mon, 12 Jun 2023 15:58:38 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id 2E1FE27BBE2; Mon, 12 Jun 2023 20:58:37 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 79d400e8; Mon, 12 Jun 2023 19:58:36 +0000 (UTC) References: <878rcp8kxq.fsf_-_@gmail.com> <87edmhxcy3.fsf@cbaines.net> <874jnc98j8.fsf@gmail.com> User-agent: mu4e 1.10.2; emacs 28.2 From: Christopher Baines Date: Mon, 12 Jun 2023 20:53:25 +0100 In-reply-to: <874jnc98j8.fsf@gmail.com> Message-ID: <87wn08tpud.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Maxim Cournoyer writes: > Hi Chris, > > [...] > >>>> +To help coordinate the merging of branches, you must create a new >>>> +guix-patches issue each time you wish to merge a branch (@pxref{The >>>> +Issue Tracker}). These issues indicate the order in which the branches >>>> +should be merged, so take a look at the open issues for merging branches >>>> +and mark the issue you create as @dfn{blocked} by the issue previously >>>> +at the back of the queue@footnote{You can mark an issue as blocked by >>>> +another by emailing @email{control@@debbugs.gnu.org} with the following >>>> +line in the body of the email: @code{block XXXXX by YYYYY}. Where >>>> +@code{XXXXX} is the number for the blocked issue, and @code{YYYYY} is >>>> +the number for the issue blocking it.}. >>> >>> Maybe by default, since the strategy would be "first come, first >>> merged", we can forego with the 'block' tags, as issues will already be >>> posted in the order (and given an increasing number) they should be >>> merged? Then the nitty-gritty details of micro-managing block tags can >>> be mentioned only when they are useful, e.g. ... >> >> That sounds fine to me. > > One disadvantage of this is that people must now manually find the > preceding merge requests on the tracker; but if we have some convention > prefix in the subject, e.g. 'MERGE' or similar (it's always implied we > merge to master branch and nowhere else, correct?), that would still > make it easy. When the tooling (build coordinator) offers a web view of > the branches to be merged that can be linked as well. There's already a webpage featuring the branches and corresponding issues, they feature in a table on [1]. The qa-frontpage makes the assumption that the issue titles include the string "Request for merging" and have the branch name in quotes, but that's just because that was used as the title for [2]. 1: https://qa.guix.gnu.org/ 2: https://issues.guix.gnu.org/63521 As you say, it would be good to settle on a convention and mandate this in contributing.texi. As for where you're merging, yes, I'm assuming you're merging to master here. > So I think it's a LGTM. Great, thanks for taking a look. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmSHeOpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XdBAw/+Ke1SNppqdtm0W0iylJiOLnpIN/27qRop ucEUVKFDgvhzBaiYSsnMMKLLJPW2cfvMrwIYunnTL/0AqY5/ATvFpO1SglSseKRf 3HW06RABEqmH0QG2J4BN4P1xNstoHm/PytE4gL0M8s+heuRjwcn1wgMp200d2rCC fss4ARw34psTJEIMHino+NtCdmixiA8X89Rge5qk4n6xN1pXqKIgsV43vXAFYiba fUYEmXZhpxBTBxTboQT/+bIpghnHII+ewpY6Nq2pEGv4LpwC0WvwL43sIPFTvg0R QzQzJwK4spclq/JQK1Nas2R6PaW/knXtGHDCx9IYLCciJuSoojDnMOXi+EVOwTJ/ yhDkoNa+7BDG1Blul1LqnJvfn/LCEuKRqw3tDyQtEDJPJ7vZH6HYUHpq0G6K7GaZ BIgmnr9o9dZkSV5fW174xiGiVYM3v7sfQ6KNUiKykC4/bkggmFPqTzVdYA4RW80p K+IuijtRuz6+/kFGxs1G5dYSDzpzfTOSiTj2EjVoxXuK1fKig3KGA5w81AMiHHSq 3OlXP5OT3lZH9t8iZH0dPHMOn8oexTy9OQ4lZccbi0kEEPqESoiNvGCixxcGNE6n DmoI7YOs22y/7GIjJ9x20F+CE/rZD3SgTRo5jmooffNA70f9lP6/AgMMF7PVGUQh e1TRmHaTXoY= =paXJ -----END PGP SIGNATURE----- --=-=-=-- From unknown Thu Sep 11 13:39:44 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Christopher Baines Subject: bug#63459: closed (Re: [bug#63459] [PATCH] doc: Rewrite the branching strategy.) Message-ID: References: <87sfawtoqn.fsf@cbaines.net> X-Gnu-PR-Message: they-closed 63459 X-Gnu-PR-Package: guix-patches X-Gnu-PR-Keywords: patch Reply-To: 63459@debbugs.gnu.org Date: Mon, 12 Jun 2023 20:23:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1686601383-1197-1" This is a multi-part message in MIME format... ------------=_1686601383-1197-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #63459: [PATCH] doc: Rewrite the branching strategy. which was filed against the guix-patches package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 63459@debbugs.gnu.org. --=20 63459: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D63459 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1686601383-1197-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 63459-done) by debbugs.gnu.org; 12 Jun 2023 20:22:31 +0000 Received: from localhost ([127.0.0.1]:40739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8o3b-0000I7-As for submit@debbugs.gnu.org; Mon, 12 Jun 2023 16:22:31 -0400 Received: from mira.cbaines.net ([212.71.252.8]:42670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q8o3Z-0000Hv-32 for 63459-done@debbugs.gnu.org; Mon, 12 Jun 2023 16:22:30 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id 1800527BBE2; Mon, 12 Jun 2023 21:22:28 +0100 (BST) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 26a7f10c; Mon, 12 Jun 2023 20:22:26 +0000 (UTC) References: User-agent: mu4e 1.10.2; emacs 28.2 From: Christopher Baines To: Christopher Baines Subject: Re: [bug#63459] [PATCH] doc: Rewrite the branching strategy. Date: Mon, 12 Jun 2023 21:19:42 +0100 In-reply-to: Message-ID: <87sfawtoqn.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63459-done Cc: 63459-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain I've now pushed this to master as 0ea096ae23fa81f05ce97e5e61c15647c0a475ec. There's still lots to improve, both within the guidance and in addition to it. Top on my list is making some requirements about the issues to open when you want to merge a branch (e.g. specifying the title format so that qa.guix.gnu.org can detect them). Thanks, Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmSHfoBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9Xeajw//fx+H8RJ7CNqfiSE6VrzJ8JfNoaTDpcpG 3Bn5ritPKPeFMp7rohvIQuxme0zmFK0J9OVLXpO1Wj0yXoyYQuv/mlO+nS5KlKOd bvHxnVvFhojREgiP9/o9BzBiTTSMbx15DIWFeokDQybMU6hjqTwu+64rMH/mRmwm xHKnYr6dHe4ly0NXLHW/qB55XRrpqsT4Z2GOFt3j8AbMK+b9kOwn5u1U3BPw69pa SfMuVa9pPOFmGUiTuU8GdW9zgPa4BWgym60ezcUknhhlrzLjJQM8QPKTBvprJZrs 91tU34wfXkT23janCTkBt3grI3rE080lM3fXnYRwPyMc9QGLgTHTPP6wBqvUlFZJ CMtfWLPU8dMnucN0tYMooQHdxO+fbsHyv9a6svcAUIzbVNRp1LXwPdOmKdEnt748 sJ7nYeRKRHRwgPyn3c4/BbpA4v0XOsQjHT1bhJFzf6ByHZvYmUtUuKfKYRH2kmjZ DUsdvSPMD2AkDJy1Y2n3oRy6mFmQqbJ6RiCOQNVT0m98T2FsLRsqQj+YZQAWDwsh vk4h7t50miloFaz2i7GSF6C0jksO+hL+dIhhaavUfx59t/6OROP4LnhyWtpuLc3J CWUOKB1uugHusgJU17U9fzVHLLxeKSC3asB2GvrQWL4Cg1imbwsstyvfQ2X7DyPB C2nUPv0ZleY= =/Cts -----END PGP SIGNATURE----- --=-=-=-- ------------=_1686601383-1197-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 12 May 2023 07:55:30 +0000 Received: from localhost ([127.0.0.1]:53999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNcf-0001Be-SE for submit@debbugs.gnu.org; Fri, 12 May 2023 03:55:30 -0400 Received: from lists.gnu.org ([209.51.188.17]:33922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNce-0001BO-CC for submit@debbugs.gnu.org; Fri, 12 May 2023 03:55:28 -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 1pxNcc-0002EQ-41 for guix-patches@gnu.org; Fri, 12 May 2023 03:55:27 -0400 Received: from mira.cbaines.net ([212.71.252.8]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pxNcZ-0001XK-QU for guix-patches@gnu.org; Fri, 12 May 2023 03:55:25 -0400 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:54d1:d5d4:280e:f699]) by mira.cbaines.net (Postfix) with ESMTPSA id 16AAB27BBEE for ; Fri, 12 May 2023 08:55:21 +0100 (BST) Received: from localhost (localhost [local]) by localhost (OpenSMTPD) with ESMTPA id 5b211ca9 for ; Fri, 12 May 2023 07:55:20 +0000 (UTC) From: Christopher Baines To: guix-patches@gnu.org Subject: [PATCH] doc: Rewrite the branching strategy. Date: Fri, 12 May 2023 08:55:20 +0100 Message-Id: X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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, UNPARSEABLE_RELAY=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Move away from using staging and core-updates, and make the strategy independant of branch names. Keep the 300 dependent threshold for changes to master, as I don't have any specific reason to change this. Most importantly, require using guix-patches issues to coordinate merging of the branches, as I think that'll address the key issues that have shown up recently where it's been unclear which branch should be merged next. * doc/contributing.texi (Submitting Patches): Rewrite branching strategy. --- doc/contributing.texi | 58 +++++++++++++++++-------------------------- 1 file changed, 23 insertions(+), 35 deletions(-) diff --git a/doc/contributing.texi b/doc/contributing.texi index 7bf350ee0d..c54910e34d 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -1264,41 +1264,29 @@ Submitting Patches @c See . @cindex branching strategy @cindex rebuild scheduling strategy -Depending on the number of dependent packages and thus the amount of -rebuilding induced, commits go to different branches, along these lines: - -@table @asis -@item 300 dependent packages or less -@code{master} branch (non-disruptive changes). - -@item between 300 and 1,800 dependent packages -@code{staging} branch (non-disruptive changes). This branch is intended -to be merged in @code{master} every 6 weeks or so. Topical changes -(e.g., an update of the GNOME stack) can instead go to a specific branch -(say, @code{gnome-updates}). This branch is not expected to be -buildable or usable until late in its development process. - -@item more than 1,800 dependent packages -@code{core-updates} branch (may include major and potentially disruptive -changes). This branch is intended to be merged in @code{master} every -6 months or so. This branch is not expected to be buildable or usable -until late in its development process. -@end table - -All these branches are @uref{https://@value{SUBSTITUTE-SERVER-1}, -tracked by our build farm} and merged into @code{master} once -everything has been successfully built. This allows us to fix issues -before they hit users, and to reduce the window during which pre-built -binaries are not available. - -When we decide to start building the @code{staging} or -@code{core-updates} branches, they will be forked and renamed with the -suffix @code{-frozen}, at which time only bug fixes may be pushed to the -frozen branches. The @code{core-updates} and @code{staging} branches -will remain open to accept patches for the next cycle. Please ask on -the mailing list or IRC if unsure where to place a patch. -@c TODO: It would be good with badges on the website that tracks these -@c branches. Or maybe even a status page. +Changes to packages with 300 dependent packages or less can be pushed to +the @code{master} branch. + +Larger changes should be first pushed to a branch other than +@code{master}. This allows for testing and for the build farms to +process the changes prior to being pushed to the @code{master} branch. + +To help coordinate the merging of branches, you must create a new +guix-patches issue each time you wish to merge a branch. These issues +indicate the order in which the branches should be merged, so take a +look at the open issues for merging branches and mark the issue you +create as blocked by the issue previously at the back of the queue. + +Normally branches will be merged in a ``first come, first merged'' +manor, tracked through the guix-patches issues. If you agree a different +order with those involved, you can track this by updating which issues +block which other issues. Therefore, to know which branch is at the +front of the queue, look for the issue which isn't blocked by any other +branch merges. + +Once a branch is at the front of the queue, wait until sufficient time +has passed for the build farms to have processed the changes, and for +the necessary testing to have happened. @item @cindex determinism, of build processes base-commit: 9d05f9a9f538061e1fdc5aedb0748d260fcf20f7 prerequisite-patch-id: ae24e25c683be86ce0b3fa1fde1bd30e3e08e248 -- 2.39.1 ------------=_1686601383-1197-1--