ubuntu-phone team mailing list archive

[James Henstridge <james.henstridge@xxxxxxxxxxxxx>]

On Tue, Apr 8, 2014 at 10:15 PM, Dimitri John Ledkov <xnox@xxxxxxxxxx> wrote:
> Imho that will still get us into a state where trunk has gazillion of
> changes and is not releasable.
> And one would have to pick the trunk apart into a landing.

It's in nobody's interest for what's in trunk and what's deployed in
the archive to diverge too far, but I don't think it is clear that
landing everything into the archive immediately and independently is
always the best option.  For larger projects with multiple people it's
likely that changes will be developed in parallel, or at a quicker
pace than you might want to go through the CI Train process.  While in
some cases you might just submit both branches to CI Train in the same
slot, in others it can help to have some staging area to make sure
they don't conflict and work together properly.  Having a trunk branch
that is one step removed from production is a decent way of handling
this.

And for non-leaf projects such as libraries, this can be even more
important.  For example, lp:unity-scopes-api has been under rapid
development as it has gained the features needed for the scopes
infrastructure.  Some of those changes have required corresponding
changes to scopes built on top of the library (we try to avoid it, but
it has happened a few times).  Rather than rolling out these breaking
changes immediately, it makes sense to batch them up to reduce the
churn for projects build on top of the library.  This is being done
via an lp:unity-scopes-api/devel branch managed through Jenkins, which
is essentially the trunk branch in all but name.

We still go through the CI Train manual integration test plans when it
comes time to merge changes from lp:unity-scopes-api/devel to
lp:unity-scopes-api though, so I don't see this as violating the goals
of CI Train.


> A better approach is to still keep trunk match the archive, however
> have multiple staging branches e.g:
> lp:project (trunk - matches the archive)
> ~team/project/next-landing
> ~team/project/landing+1 (includes next-landing)
> ~team/project/landing+2 (includes landing+1)
> ...
>
> or possibly just number/date them. This way you keep on preparing /
> merging / testing the changes, but you don't compromise any landing -
> since each landing is self-controlled as to how much changes you want
> to land. E.g. for some projects each landing would be then
> self-limited to a few branches only, with options to reconfigure with
> an urgent fix. This way something of a lower priority could be merged
> into e.g. landing+4 or a hot-fix could be fast-tracked into
> next-landing. This is similar to how e.g. continuous streams work in
> other projects like ChromeOS - security/hotfixes are fast-tracked into
> stable, yet feature-work / minor development tinkers through
> nightly->dev->testing->stable. With ability to to move things sooner /
> later. Possibly, one would want to have the N active landings be done
> in parallel by ci-train. Obviously only next-landing can land into the
> archive, and all others depend on preceding landing. But one can
> reconfigure/merge branches and have a ppa for testing without being
> arbitrarily blocked on waiting for the previous landing to complete
> (especially when it's outside of ones control) yet be able to depend
> in landing+2 on features introduced in next-landing.

Taking the unity-scopes-api project as an example again, the CI Train
MPs for landing things in the archive do not use
lp:unity-scopes-api/devel as a source: that would be crazy, since it
is a moving target and we don't know how long it will take to land.
Instead, a short lived branch of devel is created, and an MP is
created from that branch.  This way, we know exactly what will be
going into the archive and can test accordingly, while not holding up
the devel branch.

While it would certainly be possible to queue up multiple "landing+N"
branches, I don't think this is especially helpful: in general the
focus is on getting one set of changes landed rather than creating an
even deeper pipeline.


Now while the setup in unity-scopes-api works, I don't think it is
optimal.  There are a few problems that come from the Launchpad
development focus/trunk branch not actually being the focus of
development:

1. If I want to start on a new feature and do "bzr branch
lp:unity-scopes-api", I'll be working with an out of date code, and
may need to fix conflicts before my changes are usable.

2. When I push my branch to Launchpad, it will be stacked on top of
lp:unity-scopes-api.  This means that I am transferring all the
changes in lp:unity-scopes-api/devel that haven't yet landed in
addition to my own changes.

3. When submitting a merge proposal, the default target is the
development focus.  I need to remember to change this to
lp:unity-scopes-api/devel each time.

Things would be a lot simpler if we could use the trunk branch as we
did before and have the CI Train process manage a separate production
branch.

James.