Pointier point releases

Tue Mar 11 22:36:40 UTC 2014

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 <
daniel.van.vugt at canonical.com> wrote:

> 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:
>
>> 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
>> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
>>
>> 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
>>     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
>>
>>
>>     On 07/03/14 14:42, Daniel van Vugt wrote:
>>
>>         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
>>
>>
>>     --
>>     Mir-devel mailing list
>>     Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>>
>>     Modify settings or unsubscribe at:
>>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>>
>>
>>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140311/41211c26/attachment.html>