--- Begin Message ---
|
Subject: |
[PATCH] doc: Rewrite the branching strategy. |
|
Date: |
Fri, 12 May 2023 08:55:20 +0100 |
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 <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
@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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [bug#63459] [PATCH] doc: Rewrite the branching strategy. |
|
Date: |
Mon, 12 Jun 2023 21:19:42 +0100 |
|
User-agent: |
mu4e 1.10.2; emacs 28.2 |
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
signature.asc
Description: PGP signature
--- End Message ---