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