On Tue, Apr 8, 2014 at 10:15 PM, Dimitri John Ledkov <x...@ubuntu.com> 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. -- 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
