non-Unity flavours and Mir

[Scott Kitterman]

On Monday, June 17, 2013 09:32:46 PM Michael Hall wrote:
>  06/17/2013 08:37 PM, Scott Kitterman wrote:
> > On Monday, June 17, 2013 05:32:56 PM Steve Langasek wrote:
> >> On Mon, Jun 17, 2013 at 05:13:33PM -0400, Scott Kitterman wrote:
> >>> I think Jonathon's post earlier today captures the core issue:
> >>> 
> >>> On Monday, June 17, 2013 09:05:08 PM Jonathan Riddell wrote:
> >>>> On Fri, Jun 14, 2013 at 08:01:16PM +0200, Thomas Voß wrote:
> >>>>> Yup :) I think a good way forward is to coordinate a call with
> >>>>> Jonathan and Martin from KWin such that we can walk through the code
> >>>>> together and identify the central points that would need to be mapped
> >>>>> to Mir. We can then start discussing potential solutions how to add
> >>>>> KWin support for Mir.
> >>>> 
> >>>> I'm afraid I don't have interest in such a call and neither do the
> >>>> KWin maintainers.  I don't know anything about the KWin codebase or
> >>>> how to begin porting it to another platform.  KWin are busy porting it
> >>>> to Wayland, the display server with consensus across Linux distros and
> >>>> have no interest in supporting a display server with unstable API/ABI
> >>>> that is only in one distro (from a company who have a track record of
> >>>> not maintaining their features, we're having to drop indicator menu
> >>>> support in Kubuntu because it's changed API).  Porting KWin to Mir
> >>>> would take several man-months at least and ongoing maintenance and I'm
> >>>> very skeptical Canonical would take that on.
> >>> 
> >>> As long as Canonical declines to work with the rest of the free software
> >>> community,
> >> 
> >> Well, I think that's an altogether inaccurate and unfair
> >> characterization.
> >> Canonical has always been open to working with "the rest of the free
> >> software community"; what Canonical has not been willing to do is blindly
> >> follow where certain self-appointed "upstreams" would lead, when that
> >> conflicts with the business's goals.  Wayland was evaluated, and found
> >> not
> >> to be suitable as a basis for Unity (as has been discussed elsewhere) -
> >> thus, Wayland is not an upstream of Canonical (nor, TTBOMK, of any other
> >> existing distros at the moment).  Canonical has made a decision to
> >> implement its own display server / compositor, in the form of Mir, and
> >> as expressed in this thread is open to working with developers from
> >> other desktops to see whether Mir can meet their needs as well.
> >> 
> >> The KWin maintainer wasted no time after Mir was announced to make it
> >> clear
> >> that he wanted no part of it.  I think that's unfortunate, but I also
> >> don't
> >> think that says anything about *Canonical's* willingness to work with
> >> others in the free software community.
> >> 
> >>> By deciding to do Mir, Canonical decided to go on it's own path that is
> >>> not the one that the rest of the community was on.  They're still on the
> >>> path they were on and while it may be reasonable for Canonical to do
> >>> it's
> >>> own thing, I think Canonical has to also expect everyone else isn't
> >>> going
> >>> to drop their plans and toe the Canonical line about the future of
> >>> $PROJECT (it could be any number of things, in this case it's what
> >>> replaces X).  AFAICT, both KDE and Gnome are satisfied with the path
> >>> they
> >>> are on with Wayland, so Mir is not interesting for them (I know far less
> >>> about it for Gnome, but that's my understanding).
> >> 
> >> There's no expectation from Canonical's side that others will drop
> >> existing
> >> plans to "toe the Canonical line".  OTOH, as a bystander my understanding
> >> is that Wayland has yet to advance beyond the level of a pet project -
> >> not something production-ready that projects can rely on in a shipping
> >> release. So I think it would behoove projects like GNOME and KDE to give
> >> Mir a fair shake, rather than dismissing it because they've already
> >> hitched their cart to Wayland.
> >> 
> >>> I do think that the long term effect on flavors that aren't deeply
> >>> embedded in the Canonical technology set is reasonably clear and we
> >>> shouldn't try to hide it.
> >> 
> >> Certainly, flavors that are unable to align with technologies chosen for
> >> Ubuntu will find themselves with more work to do to keep up quality and
> >> be
> >> releasable.  I don't think it's a foregone conclusion that this means
> >> Kubuntu will be unreleasable because KWin will only support Wayland while
> >> Canonical will only support X and Mir in Ubuntu; but certainly someone
> >> would have to step up to provide *some* maintainable combination of
> >> components here (either Wayland in Ubuntu, or KWin with support for X or
> >> Mir backend, or...)
> >> 
> >> I'm personally optimistic that, given good will and an openness to
> >> collaboration on the part of the various upstreams, and leadership from
> >> the
> >> Kubuntu team about how the future display architecture should look for
> >> this
> >> flavor, you would find more than enough resources to help with the
> >> implementation.  But beyond the open hand the Mir developers have already
> >> offered here in this thread, this is really out of Canonical's control.
> > 
> > I agree.  This is more about consequences of decisions already taken.  I
> > don't see a good solution.
> > 
> > Scott K
> 
> Well to start with, we can all acknowledge that everybody just wants to
> build something better.  And while we obviously have different ideas
> about what that means, we can still work together when it makes sense.
> There is room enough in our ecosystem for more than one display server,
> just as there is room enough for more than one desktop environment, more
> than one GUI toolkit, and more than one distro.

Certainly.  It's certainly possible that I'm being overly pessimistic, but it 
looks to me like the path that Ubuntu is on now is more like a single company 
dominated special purpose(s) Linux variant like Android than as a broadly 
useful general purpose distribution.  As I've said before, I'm sure Canonical 
sees the business benefit in investing their engineering resources this way, 
but we shouldn't pretend the change isn't happening.  It won't be quick (I've 
no idea the timeframe), but that's pretty clearly the path.

Scott K