Monday, 17 June 2013

Re: non-Unity flavours and Mir

On Monday, June 17, 2013 04:22:41 PM Marc Deslauriers wrote:
> On 13-06-17 04:00 PM, Jonathan Riddell wrote:
> > On Fri, Jun 14, 2013 at 11:41:29AM -0400, Marc Deslauriers wrote:
> >> Do you have any more details, or opened bugs about the issues?
> >
> > An X one for example
> >
> I was looking for issues that were caused by Unity-specific patches.

I think it rather misses the point to do that. What I passed on was the
upstream kwin perspective. Given that no kwin developer actually uses Kubuntu
(they don't), it's quite likely that they may have misattributed the reasons
for things, e.g. someone either on mail or IRC in conversation on this topic
indicated that the prime driver behind pushing bleeding edge Mesa versions
wasn't Unity, but hardware support requirements. It's quite likely that an
upstream that's uninvolved with Ubuntu will understand all the reasons for all
the changes, they just see the bug reports.

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, those of us that are trying to do that are fundamentally
disadvantaged. Canonical presumably has good business reasons for behaving as
it is, so I won't even argue they should do things differently. I don't
understand the business rationale well enough to be able to say. 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.

Scott K

ubuntu-devel mailing list
Modify settings or unsubscribe at: