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.us.oracle.com//gates/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://ulhg@userland.us.oracle.com//gates/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 (https://hg.java.net/hg/solaris-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: