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