aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorLudovic Courtès <ludo@gnu.org>2017-05-13 22:24:51 +0200
committerLudovic Courtès <ludo@gnu.org>2017-05-13 22:25:23 +0200
commit916b5eba0d5d1a80b5b67669506417ef9fefafb4 (patch)
tree33caeb02017339fa22ae87135528c34887bffa98 /doc
parent4d8806c3d662c74e6d48d0f0d6ce423fce9a3a08 (diff)
downloadguix-916b5eba0d5d1a80b5b67669506417ef9fefafb4.tar
guix-916b5eba0d5d1a80b5b67669506417ef9fefafb4.tar.gz
doc: Document the branching and rebuild scheduling strategy.
* doc/contributing.texi (Submitting Patches): Document the branching scheme.
Diffstat (limited to 'doc')
-rw-r--r--doc/contributing.texi27
1 files changed, 24 insertions, 3 deletions
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 8465745ee9..925c584e42 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -345,9 +345,30 @@ For important changes, check that dependent package (if applicable) are
not affected by the change; @code{guix refresh --list-dependent
@var{package}} will help you do that (@pxref{Invoking guix refresh}).
-Packages with roughly 100 dependents or more usually have to be
-committed to a separate branch. That branch can then be built
-separately by our build farm, and later merged into @code{master} once
+@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,200 dependent packages
+@code{staging} branch (non-disruptive changes). This branch is intended
+to be merged in @code{master} every 3 weeks or so. Topical changes
+(e.g., an update of the GNOME stack) can instead go to a specific branch
+(say, @code{gnome-updates}).
+
+@item more than 1,200 dependent packages
+@code{core-updates} branch (may include major and potentially disruptive
+changes). This branch is intended to be merged in @code{master} every
+2.5 months or so.
+@end table
+
+All these branches are 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.