Subject: next mir 0.2.0

From: Kevin Gunn <[email-masked]>
Date: Tue, 13 May 2014 17:16:52 -0500

hi all,
Just a poll for feedback.
Its been a while since our 0.1.9, and since we keep devel up to snuff for
promotion to trunk we could pull at any time. Some might feel like we
should promote now. But I feel the next promotion should probably wait for
the following to land on devel:
1) the improved "non-blocking swap" (which is really deterministic swap),
which is this branch lp:~raof/mir/1hz-rendering-always
2) the custom input dispatcher which is being broken up and landed in
multiple branches, but represented by wip branch here
lp:~andreas-pokorny/mir/input-sender-split
3) any support of trusted session, which i think it covered by this branch
lp:~alan-griffiths/mir/TrustSessionHelper-gets_pid_when_trusted_client_connects_over_fd

Reason being, promotion isn't hard but always takes a while & all of these
are relatively along the path of being developed and pre-requisites for
other things (display blank policy movement to usc, enabling Qt comp, end
to end trusted session/app content sharing)
feel free to cmiiaw on any of the branch references.
Thoughts on waiting a bit for 0.2.0 ?
br,kg

---

From: Alberto Aguirre <[email-masked]>
Date: Tue, 13 May 2014 18:59:43 -0500

Yeah at least 1) should be in there.

On Tue, May 13, 2014 at 5:16 PM, Kevin Gunn <[email-masked]>wrote:

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>

---

From: Cemil Azizoglu <[email-masked]>
Date: Tue, 13 May 2014 21:08:39 -0500

In general, I wonder if the following makes sense :

- if the new content is causing ABI/API breaks, we should promote pretty
soon after it's in devel. Hopefully, that won't happen so often. If/when it
does, we don't want to sit on it for long.
        o To minimize breaks (and releases), if we are expecting work items
that will cause breaks, we should (try to) schedule them to be completed as
a batch around the same time, so they can all be promoted together.
- If there are no API/ABI breaks, we can accumulate some commits and
release at regular intervals (say, monthly?).
- If content is requested/needed externally, we promote ASAP.

-Cemil

On Tue, May 13, 2014 at 6:59 PM, Alberto Aguirre <
[email-masked]> wrote:

>> Reason being, promotion isn't hard but always takes a while & all of
>> these are relatively along the path of being developed and pre-requisites
>> for other things (display blank policy movement to usc, enabling Qt comp,
>> end to end trusted session/app content sharing)

-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA

---

From: Kevin Gunn <[email-masked]>
Date: Tue, 13 May 2014 21:40:20 -0500

This is close to what happens in a general sense.
I would say we're closer to a 2 to 3 week cycle (dependent on getting a
silo, ci-train process etc)
wrt API/ABI breaks, I do believe things will get better, but so far, the
ABI churn has not been predictable enough.

Also, keep in mind...there is a spirit of "if its not on trunk or in the
image, its not real"
So, normally I'd like to travel as fast as practical, which I think 2 weeks
is. And I was kind of assuming people were getting used to an almost
fortnightly release. Which is why I'm asking about waiting on 0.2.0, as it
will likely end up being a 5 or maybe 6 week diff from 0.1.9.

On Tue, May 13, 2014 at 9:08 PM, Cemil Azizoglu <
[email-masked]> wrote:

>         o To minimize breaks (and releases), if we are expecting work
> items that will cause breaks, we should (try to) schedule them to be
> completed as a batch around the same time, so they can all be promoted
> together.
>>> Its been a while since our 0.1.9, and since we keep devel up to snuff
>>> for promotion to trunk we could pull at any time. Some might feel like we
>>> 1) the improved "non-blocking swap" (which is really deterministic
>>> swap), which is this branch lp:~raof/mir/1hz-rendering-always

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 14 May 2014 11:12:27 +0800

I was hoping we could resolve most if not all the bugs marked as 
[regression] before rolling 0.2.0:
    https://launchpad.net/mir/+milestone/0.2.0

Two of them were known at the time of releasing 0.1.9 and I personally 
think we should wait until most of the regressions have fixes landed. 
Most of the other 10 regressions I think are "new in 0.2.0" so they have 
not technically regressed in archive at all, unless we release without 
fixing them first.

- Daniel

On 14/05/14 06:16, Kevin Gunn wrote:
> for promotion to trunk we could pull at any time. Some might feel like
> we should promote now. But I feel the next promotion should probably
> wait for the following to land on devel:
> these are relatively along the path of being developed and
> pre-requisites for other things (display blank policy movement to usc,
> enabling Qt comp, end to end trusted session/app content sharing)