doc/gate-mechanics.txt
changeset 41 50cc241a2b9a
child 3836 56af60eb6020
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/gate-mechanics.txt	Thu Nov 04 21:06:30 2010 -0500
@@ -0,0 +1,93 @@
+
+                Userland Gate Mechanics
+
+The userland consolidation operates a set of Mercurial repositories that work
+together to manage the tools, source code, and build recipies.  These
+repositories are the integration repository, gate, and external mirror.  This is
+similiar to how the Solaris ON, SFW, and other gates operates, however there
+are a few subtle differences.  In ON and other consolidations, the integration
+repository is that gate and contains the canonical source.  Once a changeset
+is committed, it becomes a part of the canonical source.  In the case of ON,
+the changeset is immediately pushed to the clone repository.  SFW and other
+consolidations push changes from their canonical gate to a clone repository
+nightly.  In the userland consolidation, developers will commit changes to the
+integration gate.  These changes will not be accepted until some basic
+validation is performed.  Once the validation completes successfully, the
+changes are accepted and pushed into the canonical source gate.
+
+Integration repository (ssh://ulhg@userland//nevada/incoming)
+	The integration gate is the Mercurial repository that all tools, source
+    code, and build recipies are committed to.  Unlike ON, SFW, and other
+    Solaris gates this source code repository does not contains the canonical
+    source for the product.  This repository is a staging area for change
+    integration and acceptance.
+
+	    hg push to integration gate
+	        |
+	        v
+	    lock gate
+	        |
+	        v
+	    validate changeset(s) -> failed --> rollback changeset(s) 
+	        |                                   |
+	        v                                   |
+	    accepted                                |
+	        |                                   |
+	        v                                   v
+	    push to clone -------------------> unlock gate
+	                                            |
+	                                            v
+	                                       update bug db
+	                                            |
+	                                            v
+	                                       notify committer
+
+    So, the basic flow works something like this:  A user pushes a changeset
+    to the integration gate.  Mercurial locks the gate to block any other
+    attempts to operate on the gate while it is validating the changeset.
+    At this point, validation is started in the background, a message is
+    displayed, and control is returned to the user.  Validation continues
+    in the background.  If validation completes successfully, the changeset(s)
+    are pushed to the clone, the gate is unlocked, the bug database is updated,
+    and the user is notified of the changeset acceptance.  If the validation
+    fails, the changeset(s) are rolled back, the gate is unlocked, and the
+    user is notified of the failure.
+
+    Changeset validation will include the following:
+        multi-delta update check
+        commit comment validation
+        bugdb validation
+      future operations
+        source archive download
+        incremental build on all architectures
+        unit test on all architectures
+        package publication for all architectures
+
+
+Canonical source repository (ssh://anon@userland//nevada/gate)
+    The clone gate is actually the mercurial repository that contains the
+    canonical tools, source code, and build recipies for the product.  It
+    should always be in a stable, buildable state.  When changes are pushed
+    to this gate, they are mirrored on the external mirror repository from
+    here.
+
+        clone update
+            |
+            v
+        push to external mirror
+            |
+            v
+        notify gatelings
+
+
+External mirror repository (ssh://[email protected]//hg/userland/gate)
+    The external mirror is the mercurial repository that contains an externally
+    accessible copy of the canonical tools, source code, and build recipies for
+    the product.  It should always be in a stable, buildable state.
+
+        external mirror update
+            |
+            v
+        notify gatelings
+
+# vi:set fdm=marker expandtab ts=4: