On Wed, Jun 13, 2012 at 1:00 PM, Roman Kennke <rkennke(a)redhat.com>
wrote:
> Today something happened, that happens over and over again
with Fedora,
> and it makes me angry. I am running Fedora 17, and so far it
worked well
> with the initial kernel 3.3.x (except that it would panic on
shutdown...
> but that was not important to me, but still embarassing).
Today I was
> notified of an important security update in the kernel.
Curiously, it
> would update from 3.3 to 3.4 (a major version upgrade, which
should not
> happen in such a core package anyway, IMO). Reboot into the
new kernel,
> everything comes up --- until I want to actually want to
read email,
> surf web, or anything that requires my network. I am on an
Intel Wifi
> card, iwlwifi module. I *can* connect to the network, but
everything is
> suuuuuuper slow or times-out every now and then. Completely
unusable.
> Reboot into the older kernel, things work well again. Now I
am left with
> the choice of running a new kernel w/o network or an
unsecure kernel.
> Thank you very much!
>
> This sort of thing I would expect in rawhide/development
builds, but not
> in a supposed-to-be stable release. I can understand the
underlying idea
> of being on the bleeding edge, but I don't want to actually
be bleeding.
> At least the base system components should not undergo major
version
> updates. Security fixes should be backported to the software
version
> that is in the stable release (1 year release cycle
shouldn't be too
> demanding for this), and only security fixes and absolutely
important
> fixes should go into stable releases. (Not to mention that
some fixes
> that I *would* consider important enough to go into stable
never end up
> there.) If major version updates are really really
necessary, they
> should undergo serious testing. I cannot believe that I am
the only one
> on an Intel Wifi chip. The way it is now, Fedora feels like
a constantly
> rolling development version that is almost unusable (because
any update,
> even security, has a fairly high risk of breaking things)
for day-to-day
> work.
>
> Bugzilla report:
>
https://bugzilla.redhat.com/show_bug.cgi?id=831571
Since I just received an email in private pointing out that
emails like
mine above might be discouraging and not helpful... let me
apologize for
this. My intention is not to bash other people's best efforts,
but
instead try to help out (otherwise I would not bother to
diligently file
bugreports and mention my concerns on this list). I am willing
to help
track down and fix the problem. However, I see a more general
problem
and maybe we can turn this into a discussion how to address
(or answer)
it.
- Why do we allow new major versions of core components into a
stable
release? What sort of testing is performed before a major
kernel update
hits Fedora stable?
- What is the policy with regards to risky changes (like
unnecessary
feature updates, ABI changes, etc) in stable?
- How can problems like the one I described above be avoided?
Is there
anything I and others can help with?
Roman
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I think the reason for shipping the latest upstream kernel is based on
the fact that backporting would be too much work.
http://fedoraproject.org/wiki/KernelRebases
Gives a good overview and probably prevents us from repeating
arguments in the discussion.
Ok, fair enough. The question remains, how can we avoid such bad things
to happen in the future? Should I regularily try out kernel builds on
their way to stable, and object to their stable-release when I find a
problem? And how would I do that? (I.e. how can I find out when a new
kernel is about to go to stable, and when to test it, etc) And what
about the other base components of the system? (Although, to be fair,
the kernel seems to be the most problematic one..)
Roman