Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

[Jan Wildeboer]

In my case (F13, x86_64 on a Lenovo X200) the .34 kernel made suspend fail. 
On laptops I think working suspend/resume should be blocker for release. It 
worked before, hence it is a regression.

Note that I am not running rawhide. Just plain F13 with its support promise. 
Suspend/Resume failing is a problem for me. The X200 is not that uncommon 
(at leat inside Red Hat).

I am forec to boot into the older kernel to work.

Jan

----- Original Message -----
From: test-bounces at lists.fedoraproject.org 
<test-bounces at lists.fedoraproject.org>
To: For testers of Fedora development releases 
<test at lists.fedoraproject.org>
Cc: test at lists.fedoraproject.org <test at lists.fedoraproject.org>
Sent: Sun Sep 05 10:24:38 2010
Subject: Re: Why was a kernel-2.6.34 pushed to updates that had un-addressedbugs.Bill Davidsen <davidsen at tmr.com> wrote:

>If they don't have time to look at everything, then maybe they should stop
>shipping kernels they haven't looked at! Really, people who needed 2.6.34 
>could
>pull it from updates-untested and the rest of us could have working 
>systems.
>
>Back in the FC3-4-5-6 days stuff released seemed to work, but in the last 
>two
>years there have been more and more things shipped which broke existing
>installations. It feels like there is more effort to get lots of stuff out 
>fast
>even if it doesn't work, if it breaks things for users, etc. ...

This is alpha test, and one objective should be to get wider testing of
new kernels (and other software) in order to have experience that directs
the choice of what to ship in the scheduled release.

However stable they may be, there is a downside to a choice to keep
old versions of software:  upstream maintenance and testing will focus on
the latest code, and users are typically told "Upgrade to the latest
release, which fixes your bug."  If Fedora chooses to keep an old kernel
or other component, it incurs what can become a serious maintenance cost
to fix problems in what has become "the Fedora version" of software.

Of course, there is a balance here.  Fedora intentionally chooses to
favor new software and technology, and a very aggressive release
schedule.  Fedora caters to software developers and users who want the
latest code, and provides a vehicle to deliver this technology to a wide
community of users.

For users who want software where the focus is on stable environment,
longevity, and more predictable support, Red Hat offers several products
that have been praised by users.  Other organizations also offer Linux
products that addres these goals.

Your question is reasonable: "Why was a kernel-2.6.34 pushed to updates
that had un-addressed bugs." but I think it has been answered correctly
and well.  In the larger sense "Does Fedora achieve a good balance
between new function and bugs fixed relative to regression problems
and old bugs?" I think the popularity of Fedora answers that
affirmatively.

Were more bugs shipped in F13 than with F3-4-5-6?  Probably, but the code
base is much larger and the release schedule more aggressive.  Also, with
many more Fedora users, more bugs are likely to be observed.

Nevertheless, there is certainly opportunity to ship fewer bugs in a
release.  We may not be able to do a lot about code quality from upstream
(aside from choices about what function to include in Fedora) but release
testing is where bugs can be identified, and where your efforts and those
of others do improve the quality of a release.

And sometimes, however uncomfortable it is, a release schedule forces
choices between alternatives that all contain problems.  A delay in
release date may help sort out critical problems, but is no panacea - it
simply changes the problem set.






-- 
test mailing list
test at lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test