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