author Craig Mohrman <>
Fri, 04 Feb 2011 16:39:42 -0800
changeset 73 ab86dc591780
parent 41 50cc241a2b9a
child 3836 56af60eb6020
permissions -rw-r--r--
7017417 missing variant for which binary in package manifest

                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
	    lock gate
	    validate changeset(s) -> failed --> rollback changeset(s) 
	        |                                   |
	        v                                   |
	    accepted                                |
	        |                                   |
	        v                                   v
	    push to clone -------------------> unlock gate
	                                       update bug db
	                                       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

        clone update
        push to external mirror
        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
        notify gatelings

# vi:set fdm=marker expandtab ts=4: