On 8 April 2014 13:30, Alberto Mardegan <alberto.marde...@canonical.com> 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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
