Subject: Pointier point releases

From: Daniel van Vugt <[email-masked]>
Date: Fri, 07 Mar 2014 14:42:41 +0800

I notice how non-trivial it is to update all the projects, rebuilds and 
packages every time we need to integrate a new Mir release into touch.

But we could make this much easier if the Mir team consciously separated 
ABI-break releases from smaller (and more frequent) minor releases. This 
would allow us to install most smaller Mir releases without having to 
update any other projects/packages. It just requires a little planning 
by the Mir team to somehow "save up" and separate ABI-changing 
proposals. I think the trouble might be worthwhile for the benefit we'd 
get in being able to do instant system integration testing on touch images.

For example, given we roughly do a Mir release every 2-3 weeks now, we 
could instead do:

A minor release more often, every week or so (no ABI changes).
A larger release (ABI break) with more intrusive changes less often 
(like monthly?).

- Daniel

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 10 Mar 2014 11:58:49 +0800

A nice clean way to approach this is to designate Mir version numbers 
like this (partly based on the current patterns):

0.1.7  Bug fixes
0.1.8  Bug fixes
0.2.0  Server ABI bump / bug fixes
0.2.1  Bug fixes
0.2.2  Bug fixes
0.2.3  Bug fixes
0.3.0  Server ABI bump / bug fixes
0.3.1  Bug fixes
1.0.0  Client ABI bump / server ABI bump / bug fixes

"Bug fixes" can also include any enhancements which don't break the 
ABIs. So effectively a Mir version number would become:

MIR_VERSION = CLIENT_ABI . SERVER_ABI_DECIMAL . FIX_REVISION
SERVER_ABI = CLIENT_ABI . SERVER_ABI_DECIMAL

This means the expected frequency (which I think is realistic) would be:

Bug fixes: Very regularly (daily/weekly)
Server ABI change: Less regular (one or two per month, to limit package 
rebuild pain).
Client ABI change: Very seldom, none planned.

This is actually quite a simple plan to implement. We don't have any 
client ABI changes on the horizon just yet, but when we do that can form 
the basis of choosing "1.0.0".

- Daniel

---

From: Kevin Gunn <[email-masked]>
Date: Mon, 10 Mar 2014 10:52:12 -0500

I'm +1 in general on the proposal.
The only thing I would correct is expectations. I think what we've proven
over the last several months is that we do actually require ABI update for
the server more weekly than monthly.

Also, we have become fairly disciplined at bumping the server .so name on
the dev branch at the point of breaking ABI or API. Which is extremely
helpful, speaking as the person designated to ride the "CI train" at the
moment. However, we had one sneak in recently...from memory,
configure_output removed.

I think the more important problem to solve for the team is to have a
centralized/remote way of building the latest dev branch + updated known
dependent components (unity-mir, platform-api,
unity-system-compositor...note, i'm leaving out xorg-server atm since its
only client api). Not only for folks to be able to easily test cooperative
features that might span say mir & unity-mir, but to also catch the
accidental server break.

I've been wrestling with using launchpad ppa, which I just want to share
has some idiosyncrasies not readily apparent. First, if you just use the
launchpad ppa builders as is, you are built on a virtualized hardy kernel -
so you have to ask to be non-virtualized from webops. Second, if you run
our Mir android integration tests they fail due to lacking access to the gl
drivers. So the ppa builders aren't quite the same as the builders on our
"dev branch ci runs" - however more similar to our "ci train" silo builds.

In parallel to me trying to get a ppa working for mir-dev, unity-mir,
platform-api, & unity-system-compositor. I think Robert was going to chase
a solution to do this with our jenkins jobs used on our dev-branch. And, I
hope he beats me in that race :) as the jenkins runs have the android
driver capability.

br,kg

On Sun, Mar 9, 2014 at 10:58 PM, Daniel van Vugt <
[email-masked]> wrote:

> A nice clean way to approach this is to designate Mir version numbers like
> this (partly based on the current patterns):
>
> 0.1.7  Bug fixes
> 0.1.8  Bug fixes
> "Bug fixes" can also include any enhancements which don't break the ABIs.
> So effectively a Mir version number would become:
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 11 Mar 2014 10:20:20 +0800

Yeah the removal of "configure_output" coming in Mir 0.1.7 is a good 
example. As I did that, I will document it thoroughly in the release 
notes of 0.1.7.

Accelerating the building of branches (as I hear racarr is working on) 
is good. But it means you're still building code for multiple projects. 
What I'm suggesting in this thread is how to remove the variable of 
having to rebuild at all.

If unity-mir is built against Mir 1.2.3 today then it should have the 
confidence that upgrading to Mir 1.2.7 will not require any rebuild. 
Having an understanding in place as to what the Mir version number 
/means/ will help us to avoid some (maybe most) rebuilds, which of 
course would be dramatically more efficient.

- Daniel

On 10/03/14 23:52, Kevin Gunn wrote:
> The only thing I would correct is expectations. I think what we've
> proven over the last several months is that we do actually require ABI
> update for the server more weekly than monthly.
>
> Also, we have become fairly disciplined at bumping the server .so name
> on the dev branch at the point of breaking ABI or API. Which is
> extremely helpful, speaking as the person designated to ride the "CI
> train" at the moment. However, we had one sneak in recently...from
> memory, configure_output removed.
>
> unity-system-compositor...note, i'm leaving out xorg-server atm since
> its only client api). Not only for folks to be able to easily test
> cooperative features that might span say mir & unity-mir, but to also
> catch the accidental server break.
>
> launchpad ppa builders as is, you are built on a virtualized hardy
> kernel - so you have to ask to be non-virtualized from webops. Second,
> if you run our Mir android integration tests they fail due to lacking
> access to the gl drivers. So the ppa builders aren't quite the same as
> the builders on our "dev branch ci runs" - however more similar to our
> "ci train" silo builds.
>
> platform-api, & unity-system-compositor. I think Robert was going to
> chase a solution to do this with our jenkins jobs used on our
> dev-branch. And, I hope he beats me in that race :) as the jenkins runs
> have the android driver capability.
>
> br,kg
>
>
>
> On Sun, Mar 9, 2014 at 10:58 PM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     A nice clean way to approach this is to designate Mir version
>     numbers like this (partly based on the current patterns):
>
>     0.1.7  Bug fixes
>     0.1.8  Bug fixes
>     Server ABI change: Less regular (one or two per month, to limit
>     package rebuild pain).
>     client ABI changes on the horizon just yet, but when we do that can
>     form the basis of choosing "1.0.0".
>
>     - Daniel
>
>
>     [email-masked] <mailto:[email-masked]>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>

---

From: Kevin DuBois <[email-masked]>
Date: Tue, 11 Mar 2014 15:36:40 -0700

I think this proposal is sensible, and its a good improvement to the way we
have to build the stack from lp:mir/devel.

If we get a bug that's filed against unity, but the bug is in mir
libraries, I find most of the time in solving the bug is spent building the
stack to verify that the bug is fixed. Hopefully being keeping track of
when things break will ease some branch-chasing.

We should figure out a way to auto-bump the debian/changelog when branches
land so the packages made from lp:mir/devel have accurate versioning. This
might take some tinkering with the jenkins scripts to designate each branch
as a abi-breaking or not.

Kevin

On Mon, Mar 10, 2014 at 7:20 PM, Daniel van Vugt <
[email-masked]> wrote:

> example. As I did that, I will document it thoroughly in the release notes
> of 0.1.7.
>
> Accelerating the building of branches (as I hear racarr is working on) is
> good. But it means you're still building code for multiple projects. What
> I'm suggesting in this thread is how to remove the variable of having to
> rebuild at all.
>
> confidence that upgrading to Mir 1.2.7 will not require any rebuild. Having
> an understanding in place as to what the Mir version number /means/ will
> help us to avoid some (maybe most) rebuilds, which of course would be
> dramatically more efficient.
>
> - Daniel
>
>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 12 Mar 2014 09:30:04 +0800

Aside from PPAs for experimentation and internal development testing, I 
don't think there should ever be "packages made from lp:mir/devel". Even 
a minor point release should be built from lp:mir. Anything that could 
hit archive will always do so via lp:mir.

On 12/03/14 06:36, Kevin DuBois wrote:
> I think this proposal is sensible, and its a good improvement to the way
> we have to build the stack from lp:mir/devel.
>
> libraries, I find most of the time in solving the bug is spent building
> the stack to verify that the bug is fixed. Hopefully being keeping track
> of when things break will ease some branch-chasing.
>
> We should figure out a way to auto-bump the debian/changelog when
> branches land so the packages made from lp:mir/devel have accurate
> versioning. This might take some tinkering with the jenkins scripts to
> designate each branch as a abi-breaking or not.
>
> Kevin
>
>
>
> On Mon, Mar 10, 2014 at 7:20 PM, Daniel van Vugt
>     Accelerating the building of branches (as I hear racarr is working
>     on) is good. But it means you're still building code for multiple
>     projects. What I'm suggesting in this thread is how to remove the
>     variable of having to rebuild at all.
>
>     If unity-mir is built against Mir 1.2.3 today then it should have
>     the confidence that upgrading to Mir 1.2.7 will not require any
>     rebuild. Having an understanding in place as to what the Mir version
>     number /means/ will help us to avoid some (maybe most) rebuilds,
>     which of course would be dramatically more efficient.
>
>     - Daniel
>
>
>
>         unity-system-compositor...__note, i'm leaving out xorg-server
>         atm since
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>         wrote:
>
>                  packages every time we need to integrate a new Mir
>         release into
>                  touch.
>
>                  But we could make this much easier if the Mir team
>         consciously
>                  separated
>                  update any other projects/packages. It just requires a
>         little
>                  planning
>                  get in being able to do instant system integration
>         testing on
>                  touch images.
>
>                  For example, given we roughly do a Mir release every
>         2-3 weeks
>                  now, we
>                  could instead do:
>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         https://lists.ubuntu.com/____mailman/listinfo/mir-devel
>         <https://lists.ubuntu.com/__mailman/listinfo/mir-devel>
>              <https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>         <https://lists.ubuntu.com/mailman/listinfo/mir-devel>>
>
>
>
>     --
>     Mir-devel mailing list

---

From: Kevin Gunn <[email-masked]>
Date: Wed, 12 Mar 2014 08:28:10 -0500

Daniel, agreed that lp:mir is release, and will only ever be what's in
archive and the touch images. But what kdub is saying, is that we do want
lp:mir/devel to reflect proper versioning as it relates to coordinating
builds of unity-mir, platform-api, unity-system-compositor, and xorg-server
against it. Doing so in such a way that we can achieve 2 things, first a
nice catch for accidental ABI breaks (or even API breaks), and second an
always reliable tip build with all those components.
Not only for our own debug but sometimes others will help verify something
but they need a set of packages to do so (e.g. QA helped by testing some
android screencasting, not yet in archive)

br,kg

On Tue, Mar 11, 2014 at 8:30 PM, Daniel van Vugt <
[email-masked]> wrote:

> don't think there should ever be "packages made from lp:mir/devel". Even a
> minor point release should be built from lp:mir. Anything that could hit
> archive will always do so via lp:mir.
>
>
>
>>                  I notice how non-trivial it is to update all the
>> projects,
>>                  rebuilds and
>>                  would allow us to install most smaller Mir releases
>> without
>>                  having to
>>                  proposals. I think the trouble might be worthwhile for
>> the
>>                  benefit we'd