Ubuntu graphic stack roadmap update
ubuntu at kitterman.com
Fri Jun 28 14:04:32 UTC 2013
On Friday, June 28, 2013 11:29:08 AM Oliver Grawert wrote:
> On Do, 2013-06-27 at 14:26 -0400, Scott Kitterman wrote:
> > As you know, display issues are very hardware specific. With the current
> > amount of testing of Kubuntu on XMir (AFAIK one developer with one
> > machine) I don't think we know anything about how well it will work for a
> > general purpose flavor like Kubuntu.
> so i read that sentence three times now (and i wonder if you did before
> sending the mail) and i can by no means find any logic in it ... you are
> claiming that the majority of bugs with Mir will be HW specific which
> means that all flavours including Ubuntu will see them on a particular
> HW ...
I did leave a word out. Display issues are ... often ... very hardware
specific. The point of that is that a few people running tests isn't sufficient
to understand how something like Mir will behave on the huge variety of
hardware that it will eventually be exposed to. Also, it is sometimes a
specific combination of hardware and software. I recall one case which it a
kwin bug that was only exposed by a specific mesa version on Intel hardware.
So no, not everyone will see the same issues.
> how does that affect you as a general purose desktop developer (do we
> have any official flavours that aren't shipping general purpose
> desktops ? (i know edubuntu and -studio are shipping special purpose app
> selections, but the desktops they ship aren't single purpose to my
> knowledge)) except that you can just throw these bugs over the fence to
> the HW/Mir/kernel teams to get them solved (or even rely on the fact
> that it will simply get fixed because other flavours see it too on that
> HW without you having to take any action at all)
There are subsets of the Ubuntu project that target very specific hardware.
For example, if a group is working on Nexus 7, then there is only ~one
hardware configuration to worry about. I agree that Unity itself isn't special
> as someone working on the top level, why do you care about HW bugs at
> all, just forward them to the experts to fix them (if collecting debug
> data for them isn't asked to much), if composite is broken on specific
> HW it will be for all of us ...
That's not always the case. Since there are multiple implementations
involved, sometimes it's specific to a combination of hardware and specific
software, but that's not really the point of this paragraph.
What I was trying to communicate (and clearly failed) is that I think there is
not nearly enough information available to say that even though XMir appears
to work well on one developer's system (and it did in the appear that way in
the video that was posted on You Tube (and the follow-up that was done last
night), that's one system. That's not nearly enough to know how it will
perform more generally.
Let me pick another example from the project's past to illustrate why I think
it's prudent for Kubuntu not to move to XMir now:
For Hardy, 8.04, Ubuntu switched to pulseaudio by default. This was a hugely
controversial decision and it caused regressions in audio for a lot of users.
The regressions were primarily due to driver bugs that were only exposed by
pulseaudio, but users don't really care which piece of software is at fault
when they system works less well after upgrade. They just want it to work.
Kubuntu did not switch to pulseaudio by default until Maverick, 11.10 and so
Precise, 12.04 was the first LTS where Kubuntu shipped with pulseaudio. By the
time we switched, most drivers had been updated to resolve the issues exposed
by pulseaudio and, while not trouble free, the switch was far smoother than
what Ubuntu experienced.
I don't think we'll know for awhile if XMir is really as generally compatible
as is currently being claimed. I believe it's being design and planned to be
compatible, but I don't believe there is enough data in evidence at this point
to know how successful it's developers have been. So even if KDE on XMir is
no better or worse than Unity on XMir (which is also an assumption), I think
it makes complete sense for Kubuntu to wait and see.
More information about the ubuntu-devel