[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora 12 QA retrospective - feedback needed



On Thu, 2009-11-26 at 01:23 +0530, Rahul Sundaram wrote:

> My personal experiences in addition to the impressions from reading all
> the end user forums, mailing lists and news sites is that Fedora 12 is a
> solid release. I request you to explicitly get feedback from atleast
> fedora-list and http://fedoraforum.org from end users directly. Adam and
> James, are you subscribed to fedora-list and keeping track of the
> discussions there?

I'm not. I just don't have time for it. I'm relying on you for that
bit :) sorry. I had to pick either the mailing list or the forums to
follow, I picked the forums.

> I think, there is room for improvement obviously:
> 
> * IMO, RCs needs to advertised loudly. We need all the testing we can
> get and more alpha or beta snapshots would help as well, I think.

We have this discussion every release. The problem is that RC testing is
a very short phase, during which multiple candidates get rolled. By the
time anyone outside of the actual physical network on which they're
located is done downloading RC1, we've probably spun RC3 already.

even despite that, public testing of RCs can _sometimes_ be useful, but
the problem is that if we publicise them any more than they're already
publicised, the single server on which they're located will bog down and
stop people who really need them from getting them fast enough. And
given the time constraints, it's practically impossible to mirror or
torrent them usefully.

> * Lot more users are trying Preupgrade and QA needs strong focus on the
> upgrade story including test days directed towards it. The small /boot
> is a major issue and another common bug (not listed in the wiki but I
> think needs to be added) is
> https://bugzilla.redhat.com/show_bug.cgi?id=538118 which makes the
> problem worse. We really need to make sure Anaconda creates a bigger
> /boot for Fedora 13, preupgrade is explicitly tested well and has solid
> workarounds for the small /boot case.

I agree, good point. Our current preupgrade testing is a bit
perfunctory.

> * KMS is still flaky in some cases. In particular, a few Intel users
> seem to be reporting lower resolution by default without nomodeset 

This is 'normal' if your EDID isn't detected: the fallback resolutions
for the KMS drivers are lower than the ones for the old UMS path, I
think (KMS fallback is 800x600 for most of the drivers, UMS fallback was
often 1024x768). I notice the latest kernel has the ATI KMS fallback
bumped to 1024x768 to match the UMS fallback, though I'm not sure if
this is entirely the right decision, I think 800x600 is actually safe on
some displays where 1024x768 isn't.

> and
> ATI performance seems to have regressed.  

This is known and being worked on.

> Although I am no fan of
> proprietary drivers, I must note that installing the proprietary Nvidia
> driver has become a bit more of a hassle.

I've been tracking that and working with RPM Fusion to mitigate it. It's
not something Fedora could really have done much about and kept in line
with our policies. There's two issues - NVIDIA does something SELinux
considers evil and blocks, and the nvidia kernel module conflicts with
the nouveau one. 

I believe the onus is on NVIDIA to fix both of these. The SELinux
blocking is legitimate and genuinely points to the NVIDIA driver doing
something it really shouldn't ought to do, I believe, and it's up to
NVIDIA to make it not do that any more. We can hardly relax the SELinux
default policies to allow something bad just because the NVIDIA
proprietary driver wants to do it.

on the nouveau conflict, we can't suppress the nouveau module loading by
default, it's needed for KMS. It's up to either NVIDIA or RPM Fusion to
handle this smoothly. It's somewhat tricky to suppress the nouveau
module entirely; you have to re-generate the initrd after blacklisting
it, otherwise it gets loaded at initrd time (to do KMS-backed graphical
boot). It's either up to RPM Fusion to do this in the packages, or up to
NVIDIA to make the module somehow co-operate with the nouveau module
(perhaps by unloading it and loading the nvidia module if you try to
start X with the nvidia driver).

I suppose what could be improved here is better communication between
Fusion and NVIDIA so NVIDIA is made aware of these issues in advance of
a Fedora release, but that's not a topic for Fedora :)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]