Gentoo Archives: gentoo-dev

From: Mike Pagano <mpagano@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo-sources - should we stable?
Date: Fri, 02 Jan 2015 19:56:08
Message-Id: 1469643.WCBe1D71WJ@crow
In Reply to: Re: [gentoo-dev] Gentoo-sources - should we stable? by Ian Stakenvicius
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