--- /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://[email protected]//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://[email protected]//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: