non-Unity flavours and Mir

[Jono Bacon]

Hi Matthias,

On Mon, Jun 17, 2013 at 4:34 PM, Matthias Klumpp <matthias at tenstral.net>wrote:

> 2013/6/18 Jono Bacon <jono at ubuntu.com>:
> > I see this as a trade-off.
> Fair point. But you can not expect KDE or GNOME to suddenly jump on
> the Mir train. Supporting a new display server is pretty damn hard, it
> took a lot of time to
> clean up all the code to abstract X dependencies and make the switch
> to a non-X displayserver possible. But after that is done, maintaining
> a new display server backend is still not easy. And KDE and GNOME have
> already put lots of work into Wayland porting, so why should everyone
> now switch to Mir, a newly created project without stable API/ABI and
> no obvious benefits except for Ubuntu support?
> So, investing time into writing code for Mir makes no sense at all
> from this point of view. There is still the option that Canonical
> contributes code for Mir to e.g. KWin. Adding Mir support to KWin in
> addition to Wayland would still be tricky, and doing it right be a lot
> of work. Also, it would make code maintenance more complicated, so it
> is understandable that upstream would reject the patches (similar
> policy is applied for systemd to keep the codebase clean), as well as
> I don't see Canonical writing patches for KWin/KDE - it just doesn't
> make sense for the company to invest money into something which isn't
> their primary product.
> So I am afraid that this situation cannot be easily solved, and that
> "you don't contribute to my project" accusations from any side will
> not help solving it too.
>
>
I completely understand Jonathan and Scott's perspective - if Wayland has
already been decided as the primary display server for those projects and
work has already been invested, I entirely understand why there would be
less interest in Mir. I also appreciate that maintaining a Mir backend is a
lot of work.

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.



> > Jonathan raised a valid point about KDE's needs and made it clear that
> the
> > Kubuntu team would prefer not to have to maintain Wayland as a
> foundational
> > piece in order to deliver Kubuntu. Obviously this work can be performed
> by
> > the Kubuntu team (or anyone else) if they wish to do so; the archive
> > welcomes components that don't serve Canonical's needs.
> >
> > Canonical will of course be maintaining Mir as a core piece of
> > infrastructure in the archive, and arguably encouraging Mir support in
> > upstream KDE will help to alleviate this issue, but given that the Mir
> team
> > are very open to supporting this outcome but both yourself and Jonathan
> are
> > resistant to this, I am not sure what other options there are.
> It is not about people being resistant. It is simple technical reasons
> which make it difficult to resolve this situation.
> In future, GNOME and KDE will share Wayland as display server, and
> Ubuntu/Unity will have Mir, effectively breaking the infrastructure
> unity we had between desktops apart.
> From the current Mir specs, I also fear that replacing mir will be
> easily possible (it is started at early boot and many things are
> planned to connect to it as soon as possible - and Canonical would
> have to think about a non-Mir situation when designing that
> infrastructure - not sure if that will be done) But that's a different
> topic.
>
> I understand the perspective that Mir can be seen as fragmenting the
eco-system, but people make the same arguments at KDE and GNOME (and of
course Unity), which are also infrastructure pieces. Sometimes a little
choice can be a good thing; I am sure that Mir has already triggered some
even more fervent Wayland development. :-)

   Jono

-- 
Jono Bacon
Ubuntu Community Manager
www.ubuntu.com / www.jonobacon.org
www.identi.ca/jonobacon www.twitter.com/jonobacon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130617/07b9e4f2/attachment.html>