On Friday, January 02, 2015 01:10:21 PM Ian Stakenvicius wrote: Resending as I replied to Ian instead of the list by accident. (sorry, Ian)
> On 02/01/15 12:25 PM, Mike Pagano wrote: > > Hello, Everyone, > > > > Are there solid arguments for stabilizing any version of > > gentoo-sources? I think the valid arguments for not stabilizing > > gentoo-sources can be garnered from the thread about not > > stabilizing vanilla-sources[1]. > > > > This is in no way complaining about how long it takes to stabilize > > a kernel. It's just a fact that by the time we do stabilizing one, > > there might be many, many kernel versions released for that 3.X > > branch that contains security fixes for which the stable version > > will not have. Kernel versions are coming out 1-2 a week at this > > point. > > > > I feel we are giving users a false sense of security, and maybe it > > would be better for them to upgrade faster than they are doing now > > if they are only using stable kernels. > > > > Having stable kernels around keeps me from deleting these old, > > potentially vulnerable releases.[2] > > > > Mike > > > > [1] http://marc.info/?l=gentoo-kernel&m=137182668616082&w=2 [2] > > http://packages.gentoo.org/package/sys-kernel/gentoo-sources > > The thing about stable gentoo-sources is that it shows that it's been > tested, and ideally that testing's been done against the rdeps of the > kernel package too (ie, external modules). For instance, I like that > I can generally expect vbox-modules and tp_smapi and bbswitch to > emerge against whatever the current-stable gentoo-sources kernel is, > whereas with the ~arch one(s) I don't hold any such expectation > (although it's nice when it does). You should *definitely* not assume out of kernel modules are stable (or even compile, install or run) on any stable version. Kernel stabilization has never been held up by out of kernel modules. They are not part of the decision on whether or not a kernel should be stabilized. > Similarly, when there are known functionality issues that do not have > an upstream fix (nor one scheduled for some time), like say, intel drm > being broken except for ~arch or -9999 xorg/libdrm/xf86-video-intel , > I think it's pertinent that the newer versions stay ~arch until a fix > is developed and available -- the stable kernel being pegged at 3.4.9 > for a long time is a good example of this. Some Arch members have told me that stabilizing kernel does not include much more than a compile and boot test. Some run it for a few days, but the mixture of hardware and versions out there really precludes an all encompassing blessing. > That said, given the frequency of security updates, I do think it > makes sense to try and keep the stabilization of LTS kernel versions > in sync with upstream as much as possible, including > quick-stabilization whenever we can. Hopefully those security > backports don't usually change functionality and features much, > although if they do then perhaps we need to hold off on their > stabilization for a little while too.. And that is the problem. We can't keep up and still with a straight face tell user's *this* is the kernel you should run. > Makes sense or am I way off base? Thanks for responding, MIke -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
