Pointier point releases
Kevin Gunn
kevin.gunn at canonical.com
Wed Mar 12 13:28:10 UTC 2014
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 <
daniel.van.vugt at canonical.com> wrote:
> 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.
>>
>> 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 <mailto: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>
>> <mailto: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>
>> <mailto: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>
>>
>> <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 <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/20140312/a37a430e/attachment.html>
More information about the Mir-devel
mailing list