This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 678116 (F15GNOMEfail)

Summary: Tracker: F15 driver/hardware incompatibilities with GNOME 3
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: distributionAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact: Bill Nottingham <notting>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: mcepl, mclasen, robatino, rvokal, walters
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 13:29:12 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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    
Bug Blocks:    

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 5 Matěj Cepl 2011-04-26 06:16:10 EDT
Why is this not blocking F15Blocker (aka bug 617261)?
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