On Thu, 2011-02-17 at 10:47 -0500, Colin Walters wrote:
On Thu, Feb 17, 2011 at 9:01 AM, Matthias Clasen mclasen@redhat.com wrote:
On Wed, 2011-02-16 at 11:21 -0800, Adam Williamson wrote:
Hey, folks. Just a note that I set up a tracker bug for known cases where trying to start GNOME 3 results in something totally unusable - Shell fails and fallback does not work correctly. So far there's a couple of bugs blocking it. The tracker is https://bugzilla.redhat.com/show_bug.cgi?id=678116 , it has the alias F15GNOMEfail. Please add any appropriate bugs to it, for convenience. thanks!
Thanks, that is useful. Fallback is under active development atm.
I think we need to distinguish between hardware/driver specifc bugs versus general ones.
In fixing the bugs, sure...I think having a single list of all the known instances of 'houston, we have a problem' is helpful though.
Both of the ones on the list look hardware-specific.
Well, I mean, I think just about _all_ bugs of this kind are going to be hardware-specific somehow. The only way that wouldn't be the case is if the fallback mechanism were somehow utterly and completely broken in implementation; once you've written a fallback mechanism that at least theoretically does what it's supposed to do, all bugs are 'corner cases', yes?
Fixing these kinds of things will involve at a minimum a lot of back and forth with the reporter, running tools, looking at output, etc. We may be able to do some of this for F15, but barring some major jump in manpower, it's unlikely we can do *all* of them.
Sure; I'm not assuming we will. I just want to have a single place where we can quickly go to get an overview of such bugs.
I think we're going to need to have an always-fallback hardware blacklist somewhere. Where exactly that lives and how it works is up for debate. I'd strawman that we make a new module/RPM "gnome-shell-blacklist" and insert it in the startup path, but better ideas are welcome.
That's up to you folks :)