Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Tracker: F15 driver/hardware incompatibilities with GNOME 3|
|Product:||[Fedora] Fedora||Reporter:||Adam Williamson <awilliam>|
|Component:||distribution||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED WONTFIX||QA Contact:||Bill Nottingham <notting>|
|Version:||15||CC:||mcepl, mclasen, robatino, rvokal, walters|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-07 13:29:12 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||671294, 672117, 675010, 675021, 676189, 676808, 677310, 677368, 678115, 678757, 678803, 679015, 679579, 680207, 680252, 680491, 680751, 681273, 681740, 682046, 682063, 683691, 695349|
Description Adam Williamson 2011-02-16 14:08:38 EST
This is a tracker bug to keep track of all known cases in F15 where GNOME Shell does not load correctly and the fallback to 'classic GNOME' (panel+nautilus) does not work; i.e., where attempting to enter GNOME results in an unusable system (but other desktops will work).
Comment 1 Colin Walters 2011-02-17 11:54:34 EST
In bugs added to this, we need to collect a lot of hardware information. See: http://fedoraproject.org/wiki/How_to_debug_Xorg_problems
Comment 2 Colin Walters 2011-02-28 09:34:17 EST
Peter, I don't think that all of the mutter/gnome-shell crashes make sense here; most of the ones you've added are likely to be hardware independent (e.g. 680491 and 680252), and also I don't think they blocked login. Memory leaks aren't also related to this bug.
Comment 3 Peter Robinson 2011-03-01 21:50:31 EST
(In reply to comment #2) > Peter, I don't think that all of the mutter/gnome-shell crashes make sense > here; most of the ones you've added are likely to be hardware independent (e.g. > 680491 and 680252), and also I don't think they blocked login. Memory leaks > aren't also related to this bug. To quote the title of the bug "Tracker: F15 driver/hardware incompatibilities with GNOME 3" so based on that definition it makes perfect sense.
Comment 4 Colin Walters 2011-03-02 16:00:42 EST
(In reply to comment #3) > (In reply to comment #2) > > Peter, I don't think that all of the mutter/gnome-shell crashes make sense > > here; most of the ones you've added are likely to be hardware independent (e.g. > > 680491 and 680252), and also I don't think they blocked login. Memory leaks > > aren't also related to this bug. > > To quote the title of the bug "Tracker: F15 driver/hardware incompatibilities > with GNOME 3" so based on that definition it makes perfect sense. Huh? No, look at Adam's original message here: "This is a tracker bug to keep track of all known cases in F15 where GNOME Shell does not load correctly and the fallback to 'classic GNOME' (panel+nautilus) does not work;" I appreciate the visibility for some of the bugs and they ARE important, but it's confusing to conflate them.
Comment 6 Adam Williamson 2011-04-26 11:05:48 EDT
Because single-card specific issues aren't blockers, certainly not automatic blockers. If any of them seem likely to affect a wide range of people, please flag them as blockers individually.
Comment 7 Matěj Cepl 2011-04-26 11:31:31 EDT
(In reply to comment #6) > Because single-card specific issues aren't blockers, certainly not automatic > blockers. If any of them seem likely to affect a wide range of people, please > flag them as blockers individually. I am not saying that Xorg should support all cards … really, Adam, you should know that I wouldn't think so. What I meant was that gnome-shell (or mutter or whatever is responsible for the decision) shouldn't try to run with OpenGL when it is not available (e.g., see bug 679579 which I added on the list of bugs blocking this one), but fall to fallback mode. That is IMHO sensible and should be required for F15 GA.
Comment 8 Adam Williamson 2011-04-26 12:24:06 EDT
That's still a system-specific problem and as I said we have always not automatically considered those blockers. Would we delay F15's release because fallback detection fails on a single system? Probably not. Fallback detection is actually pretty complex and guaranteeing it will always work is a bit of an optimistic position, particularly for F15.
Comment 9 Adam Williamson 2011-04-26 12:25:03 EDT
To give an analogy, we've often shipped with known bugs where the system would try to use a native driver and hang at a black screen; we did not mandate that the release not ship until all such cases were detected and made to fall back to VESA automatically.
Comment 10 Fedora End Of Life 2012-08-07 13:29:14 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping