----- Original Message ----- > From: "Roman Kennke" <rkennke@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
