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