On 13/10/16 02:59, Daniel van Vugt wrote: > 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. > > We have been mindful of reducing ABI breaks for years but that gets > 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. > 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. I disagree. We must make it a goal, assess progress towards it, and plan activities to support it. Otherwise it will not happen! -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
