Guys, I had an interesting chat with Saviq today (on #ubuntu-unity) about his proposed approach to CI (focussed on QtMir).
He's planning to introduce a branch that CI (including autolanding) can target so that MPs can land without being released. I'm not sure of the final terminology that will be introduced, but I'd like to see it to work pretty much as our "trunk" (even if it is called "staging" or "sausage") - i.e. continuously updated with all the "Approved" development work. Having this new branch confers a number of advantages, it is easy to find the latest state of development and build upon it, integration issues can be detected before the release process starts, and we have the opportunity to add pre-release additional automation. Saviq has a reasonable constraint on MPs that land there - that they build against the released version of Mir so as not to tie a QtMir release to a Mir one. So I'd suggest that any "compatibility" changes we propose are dressed suitably with "#if MIR_SERVER_VERSION >= MIR_VERSION_NUMBER(0, XX, 0)". I think that will largely remove the need to actively maintain devel-mir-next - as the changes can land. When we release Mir we can select one of three options: "no changes" (in which case "devel-mir-next" would be irrelevant); "all changes" (in which case we release "sausage"); or, we can "cherry pick" the compatibility changes to "devel-mir-next" during the release. The additional pre-release automation we can introduce with this approach is to build the "sausage" branch of QtMir against Mir trunk during autolanding and to add that build to ppa:mir-team/staging. All of this will make it easier to detect and address problems before starting a release. Thoughts, suggestions, volunteers? Alan -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
