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!
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.
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. Both of the ones on the list look hardware-specific. 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.
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.
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 :)
On Thu, Feb 17, 2011 at 11:32 AM, Adam Williamson awilliam@redhat.com wrote:
Well, I mean, I think just about _all_ bugs of this kind are going to be hardware-specific somehow.
Unfortunately not, see for example: https://bugzilla.gnome.org/show_bug.cgi?id=642367
I can also imagine missing or superfluous packages being a problem (remember our upgrade mechanisms are currently defined to by default not pull in new packages from the OS base, or remove old ones we don't want).
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?
I'm fine with the non-hardware bugs being individual, I don't think we need a tracker. So I'll just retitle and comment in the current one to make things more clear. Thanks!
desktop@lists.fedoraproject.org