ubuntu-phone team mailing list archive

[Dimitri John Ledkov <xnox@xxxxxxxxxx>]

On 8 April 2014 13:30, Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx> wrote:
>
> Hi all!
>   At the USD there was a session about the landing process, and some
> people brought up the point that having the "trunk" branch synchronized
> with the archive was inconvenient for developers:
>
>   https://www.youtube.com/watch?v=Igj-JyUNGPU#t=36m13s
>
> In the last 5 minutes of the session, a solution was proposed: leaving
> "trunk" for development purpose (like it was before the CI train
> started) and push the landed commits into other branches, such as
> "trusty". However no decision was taken, other than continuing the
> discussion on the mailing list. I've been eagerly waiting for it, but
> since almost a month has passed and I haven't seen this discussion being
> brought up, here it is. :-)
>
> I think this would be a very good time to implement this proposal, since
> trusty is going to be released soon, and as soon as the Upstarting
> Unicorn (this would be a wonderful name, admit it) gets open for
> development, it would not be very clear what "trunk" is synched to.
>
> So, what's the deal? :-)
>

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.

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.

-- 
Regards,

Dimitri.