next mir 0.2.0

[Kevin Gunn]

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 <
cemil.azizoglu at canonical.com> wrote:

> 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 <
> alberto.aguirre at canonical.com> wrote:
>
>> Yeah at least 1) should be in there.
>>
>>
>> On Tue, May 13, 2014 at 5:16 PM, Kevin Gunn <kevin.gunn at canonical.com>wrote:
>>
>>> 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
>>>
>>> --
>>> Mir-devel mailing list
>>> Mir-devel at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> 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
>>
>>
>
>
> --
> Cemil Azizoglu
> Mir Display Server - Team Lead
> Canonical USA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140513/dd6c7f22/attachment-0001.html>