QtMir and "devel-mir-next"

[Alan Griffiths]

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