Important kernel update should not break stuff

Aleksandar Kurtakov akurtako at redhat.com
Wed Jun 13 12:31:59 UTC 2012



----- Original Message -----
> From: "Roman Kennke" <rkennke at redhat.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Wednesday, June 13, 2012 3:15:14 PM
> Subject: Re: Important kernel update should not break stuff
> 
> 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..)

Try having updates-testing repo enabled test and provide karma via bodhi. +1 is as needed as -1 as without it we never know whether people simply installed and it worked so they stopped at that point. See http://fedoraproject.org/wiki/Bodhi for details. There is also fedora-easy-karma to ease mass reporting via bodhi.
Note that this would not make it easier for you short term as you would spot the problems just a bit earlier. But if enough people do that problems might even be spotted before you update next time and the build untagged so you never see the broken build/update at all.
This kind of workflow is effective only if we manage to gather critical mass.

Regards,
Alex

> 
> Roman
> 
> 
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


More information about the devel mailing list