Pointier point releases
Daniel van Vugt
daniel.van.vugt at canonical.com
Wed Mar 12 01:30:04 UTC 2014
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>
>
>
More information about the Mir-devel
mailing list