Tuesday 18 June 2013

Re: non-Unity flavours and Mir




On Mon, Jun 17, 2013 at 11:06 PM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
Hey Jono,

I just want to chime in with my impressions from various discussions
and talks to clarify the emotional situation.  FWIW, I do not have any
opinion about which technology is better -- I know nothing about this
stuff, just summarizing what I hear/read.


I think your guidance and input is always welcome, Martin! :-)
 
Jono Bacon [2013-06-17 16:47 -0700]:
> My primary point was in response to "Canonical declines to work with the
> rest of the free software community"; I think this is an example of us
> being very eager and open to engage with upstream. I think we are doing the
> best we can, but entirely understand if upstream are uninterested in
> investing their time in Mir.

It seems the main gripe of GNOME, KDE, and Wayland itself are that
there was no such sign of that before the Mir decision -- there have
been no discussions at all with the Wayland developers about what we
would need from it and how to adapt the Wayland protocol to Unity's
needs. Now, I do understand that the Wayland protocol has certainly
been looked at, but (1) what has been published from that decision
making process has not been technically very convincing to these
communities, and (2) it would have been more effective/polite to
discuss the technical difficulties as a first step; people like Daniel
Stone have a vast technical experience and are not hard to reach (he
had even worked for Canonical for several years).


Agreed. Speaking personally, I would have preferred if we had been able to discuss this more openly from the beginning (I would always prefer things that way), but I guess it is what it is; it wasn't my decision to make. I agree that this no doubt factors into the decision-making upstream about Mir.
 
So I guess we need to accept that they are not entirely happy about
this result and thus won't be eager to drop all their plans and work
to jump on Mir.

I think we do accept that; no one is denying the frustrations that upstreams feel about the announcement of Mir, I think where there is a point of contention is when that frustration completely halts any further discussions around solving the problems raised in this thread. These are shared problems in our eco-system.

Ever since Mir was announced we have been working hard to be as open, transparent, and collaborative as possible. The open discussion on the list/channel, weekly status updates, clear on-ramp for people to participate, and offers of working with upstreams to help discuss and evaluate Mir backends is what we are doing to try and remedy the frustrations of the past and move things forward. I am not expecting upstream to simply use Mir, but I am expecting upstream to at least have a discussion and an open mind about options moving forward as opposed to just slamming that door shut.
 
I think the best way for us to contiue to engage with upstreams at
this point is to make sure that the Wayland protocol can work on
Ubuntu. I don't see support for multiple protocols happening in
GNOME/KDE/others, as that's quite contrary to every project's goal
(including Unity!)

That is definitely one option. From my perspective I see the following options:

 1. Wayland is pulled in from Debian and maintained in Ubuntu by the community and Kubuntu and other flavors can use that. This will require community participation.
 2. Upstream evaluates the work involved in building a Mir back-end, or at least works with their own community and the Ubuntu community to see if someone wishes to build this. Canonical would provide support and mentoring around this work.
 3. Upstream runs their DE on XMir on Mir. I am not sure if this is an option, but I would assume it is. This of course requires an X backend for the DE. I suspect this will be fine over the next few years anyway as not all distros are going to immediately switch to Wayland.

I agree that (1) would be the least work for our flavors, but this is not something Canonical is likely to employ staff to maintain, so maybe one option is that the flavors work together to share the workload here?

   Jono