On Monday, June 17, 2013 05:54:25 PM Michael Hall wrote:
> On 06/17/2013 05:13 PM, Scott Kitterman wrote:
> > 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
> >>> https://bugs.kde.org/show_bug.cgi?id=xrr-ubuntu
> >> 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
> This thread is filled with offers from Canonical engineers to work with
> the rest of the free software community to make Mir usable and useful
> for their projects.
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
The issue isn't that Canonical engineers aren't willing to work with other
people on integrating Mir, it's that because Mir is Ubuntu unique, has no
stable API/ABI, conflicts with other priorities, etc., integrating Mir is
simply not an interesting prospect for upstreams.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel