<div dir="ltr">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. <div> 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)</div><div> </div><div>br,kg </div> </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Mar 11, 2014 at 8:30 PM, Daniel van Vugt <<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div class=""> On 12/03/14 06:36, Kevin DuBois wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""> 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 </div> <<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a> <mailto:<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>>><div> <div class="h5"> 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, </div></div> unity-system-compositor...__note, i'm leaving out xorg-server<div><div class="h5"> 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 <<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a> <mailto:<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>> </div></div> <mailto:<a href="mailto:daniel.van.vugt@" target="_blank">daniel.van.vugt@</a>__<a href="http://canonical.com" target="_blank">canonical.com</a><div><div class="h5"> <mailto:<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>>>> 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 <a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a> <mailto:<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a>> </div> </div> <mailto:<a href="mailto:Mir-devel@lists." target="_blank">Mir-devel@lists.</a>__<a href="http://ubuntu.com" target="_blank">ubuntu.com</a><div class=""> <mailto:<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a>>> Modify settings or unsubscribe at: </div> <a href="https://lists.ubuntu.com/____mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/____mailman/listinfo/mir-devel</a> <<a href="https://lists.ubuntu.com/__mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/__mailman/listinfo/mir-devel</a>><div class=""> <<a href="https://lists.ubuntu.com/__mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/__mailman/listinfo/mir-devel</a> <<a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a>>> -- Mir-devel mailing list <a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a> <mailto:<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a>> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/__mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/__mailman/listinfo/mir-devel</a> <<a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a>> </div></blockquote><div class="HOEnZb"><div class="h5"> -- Mir-devel mailing list <a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a> </div></div></blockquote></div> </div>