Subject: Re: Mir in Ubuntu

From: Alan Griffiths <[email-masked]>
Date: Tue, 28 May 2013 10:30:20 +0100

On 27/05/13 07:19, Christopher James Halse Rogers wrote:
>
> Since the system compositor depends on the Mir server API, which we've
> made no effort to make ABI-stable, I don't think we can reasonably
> autoland mir+unity-system-compositor into the distro. 

We've always said "you don't need it (yet)" but the time has come to
have a plan for stabilizing the MIR ABI (and also the underlying protocol).

---

From: Robert Ancell <[email-masked]>
Date: Wed, 29 May 2013 15:59:29 +1200

Periodic releases sound good, I'd vote for just stamping the staging
packages weekly if they're working well.

I think post release we just say "update to the PPA if something is broken"
- it's only meant to be a preview anyway.

On Mon, May 27, 2013 at 6:19 PM, Christopher James Halse Rogers <
[email-masked]> wrote:

> It looks like it's about time to land some of Mir¹ in Ubuntu.
>
> made no effort to make ABI-stable, I don't think we can reasonably autoland
> mir+unity-system-compositor into the distro.
>
> This probably means that we should do some form of periodic releases,
> which go in the distro. I think something like a weekly or fortnightly
> release would be appropriate.
>
> This also raises the question of how much support, in the form of
> post-release stable updates, we'll give the Mir in desktop 13.10 - my
> current understanding is “basically none”, but we'll need to think about
> branching a stable branch etc if that's incorrect.
>
> ¹: https://blueprints.launchpad.**net/ubuntu/+spec/client-1303-**mir-xorg<https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-xorg>
>
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>

---

From: Robert Ancell <[email-masked]>
Date: Wed, 29 May 2013 16:03:36 +1200

My indication is we're still in the processes of changing a lot of these
interfaces particularly in response to the Unity shell consuming it. I
don't think we can reasonably expect to start stabilising until the shell
has the majority of features working.

So we're currently at step 3 on a journey like:
1. Prototype interfaces
2. Create interfaces based on what we think a shell needs
3. Refactor interfaces in response to real shells consuming it
4. Remove interfaces that turned out to not be required
5. Give API/ABI guarantees

On Tue, May 28, 2013 at 9:30 PM, Alan Griffiths <
[email-masked]> wrote:

> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 05 Jun 2013 11:34:22 +0800

The protocol stability is not a top priority yet. Because it's totally 
hidden behind the API. Protocol changes can still occur with careful 
package versioning. Because we can continue to release updates to the 
shared mir client library, with opaque changes to the protocol.

It's the API/ABI we need to stabilize sooner because we can't control 
the release of third-party apps/toolkits/shells once they start appearing.

The protocol details don't matter until/unless you have multiple 
implementations the protocol. And for Mir, that's a long way off.