Subject: Re: Mir Version 1, stable ABIs and licences

From: Daniel van Vugt <[email-masked]>
Date: Tue, 4 Oct 2016 16:03:46 +0800

This email thread is a mess. Please enable comments in the doc.

Also I suggest making this a public discussion (CC'd).

On 04/10/16 00:46, Alan Griffiths wrote:
> A document to start the discussion:
>
>
> https://docs.google.com/document/d/1WryM41-PPg011iFIe7AFkG_FWdB4JloMNkDV1RxP36I/
>
>

---

From: Alan Griffiths <[email-masked]>
Date: Fri, 7 Oct 2016 16:24:13 +0100

> Also I suggest making this a public discussion (CC'd).
Done.

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 13 Oct 2016 09:59:43 +0800

My personal view is that we should drop this discussion.

We have been mindful of reducing ABI breaks for years but that gets 
trumped by the need to implement missing features etc.

Mir code landings have been extremely active recently, with thousands of 
lines changing every day or so. And to me that's the opposite of what 
would be happening near a maturation milestone.

I think we should let maturation happen organically. When the changes 
slow down and when we actually haven't broken ABIs for a while, that 
would be the right time to have this discussion.

- Daniel

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 13 Oct 2016 10:06:15 +0800

Alternatively, we can skip the whole "what constitutes 1.0" discussion 
and do the fashionable thing: just make version 0.26 into version 26. :)

---

From: Cemil Azizoglu <[email-masked]>
Date: Wed, 12 Oct 2016 22:43:05 -0500

> We have been mindful of reducing ABI breaks for years but that gets trumped
> by the need to implement missing features etc.
>
> lines changing every day or so. And to me that's the opposite of what would
> be happening near a maturation milestone.

I agree with you that we have a pretty high code churn. I also agree
that it is, to a certain degree, an indication of immaturity. I
believe, though, if we don't talk about this and don't have a target
to aim for, we'll never get there.

Also, as we upstream Mir support in various projects/toolkits/etc,
we'll be committing to a set of published interfaces, which should in
turn keep us honest and help us maintain those interfaces, instead of
us being too quick to break them because breaking them doesn't really
have much of an impact on things. At least, that's my hope.

-Cemil

---

From: Alan Griffiths <[email-masked]>
Date: Thu, 13 Oct 2016 10:33:09 +0100

> My personal view is that we should drop this discussion.

I disagree. The team is meeting IRL next week and should further discuss
these issues. Without the current discussion, however, we would not be
prepared.

> trumped by the need to implement missing features etc.

There is nothing inherent in adding features that requires ABI breaks,
it is simply a design trade-off. We have made different choices for
different ABIs - the client ABI has not broken for ten releases now. The
server ABI has only *not* broken for one release.

We now have a likely consensus on an approach for stabilizing the server
ABI. Vis: recommend using libmiral for shell development and keep
libmiral and libmircore ABI stable.

> Mir code landings have been extremely active recently, with thousands
> of lines changing every day or so. And to me that's the opposite of
> what would be happening near a maturation milestone.

A lot of this churn is around the graphics and input stacks, which I
agree are not yet mature enough to commit to fixing the APIs we have
right now. But it is extremely important to consider what is needed to
achieve stability,

My personal view is that we now have enough "stacks" working (at least
experimentally) to refine the useful abstractions. That will take some
time, but it is important to call out the need for this and to
prioritise the effort.

> would be the right time to have this discussion.

I disagree. We must make it a goal, assess progress towards it, and plan
activities to support it. Otherwise it will not happen!

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 24 Oct 2016 11:36:36 +0100

On 13/10/16 10:33, Alan Griffiths wrote:
> The team is meeting IRL next week and should further discuss
> these issues.

I've updated the discussion doc
(https://docs.google.com/document/d/1WryM41-PPg011iFIe7AFkG_FWdB4JloMNkDV1RxP36I)
to reflect my notes of these discussions. Please help fix anything I got
wrong.