Important kernel update should not break stuff

[Roman Kennke]

Am Mittwoch, den 13.06.2012, 13:05 +0100 schrieb Johannes Lips:
> 
> 
> On Wed, Jun 13, 2012 at 1:00 PM, Roman Kennke <rkennke at 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 at 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