1 |
On Thu, Jun 27, 2013 at 04:03:51PM -0400, Anthony G. Basile wrote: |
2 |
> On 06/27/2013 03:45 PM, Mike Pagano wrote: |
3 |
> > On Mon, Jun 24, 2013 at 09:27:10AM -0700, Greg KH wrote: |
4 |
> >> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote: |
5 |
> >>> On Fri, 21 Jun 2013 20:42:44 -0700 |
6 |
> >>> Greg KH <greg@×××××.com> wrote: |
7 |
> >>> |
8 |
> >>>> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote: |
9 |
> >>>>> On Fri, 21 Jun 2013 17:13:03 -0700 |
10 |
> >>>>> Greg KH <gregkh@g.o> wrote: |
11 |
> >>>>> |
12 |
> >>>>>> Great! But as only the latest version released is "stable", |
13 |
> >>>>>> that's all that should stick around, right? |
14 |
> >>>>> Tricky decision to make. Do we really want to force people's kernel |
15 |
> >>>>> sources to unmerge every single time you push a new version? Which |
16 |
> >>>>> on its own turn, forces them to build and install the new kernel. |
17 |
> >>>> If they are following the vanilla kernels, isn't that what people |
18 |
> >>>> expect? The latest stable-kernel-of-the-week, as that's what I'm |
19 |
> >>>> releasing. They don't have to do an update if they don't want to :) |
20 |
> >>> If we don't keep around other ebuilds their sources will unexpectedly |
21 |
> >>> unmerge upon a dependency clean; they can only stop it if they see it |
22 |
> >>> in the list of packages that will be unmerged, and do something to |
23 |
> >>> specifically keep them. |
24 |
> >> True, so we can keep around 3-4 older ebuilds if needed, per kernel |
25 |
> >> release. But who really does a dependency clean these days, I've never |
26 |
> >> done one :) |
27 |
> >> |
28 |
> >> So, what's the next step? Should I announce the change to -dev? Anyone |
29 |
> >> else really object to it? Other thoughts? |
30 |
> >> |
31 |
> >> thanks, |
32 |
> >> |
33 |
> >> greg k-h |
34 |
> >> |
35 |
> > Are we agreed on a few facts? |
36 |
> > |
37 |
> > 1. Upstream release rate is now a much higher 1-2 kernels a week. |
38 |
> > 2. Very frequently, these releases contain security fixes. |
39 |
> > 3. This rate of release puts arch teams in a difficult position, since |
40 |
> > it is unsustainable to try to keep up tp date with stabilization |
41 |
> > 4. By continuing the policy of providing a stable kernel version, Gentoo |
42 |
> > is giving a false sense of security to its users, since by the time the |
43 |
> > kernel does get stabilized, a newer version more with more security |
44 |
> > fixes is almost always already released. |
45 |
> > |
46 |
> > Auto stabling keywords again will give that false impression of Gentoo |
47 |
> > QA on a particular arch, so I don't think I would want that. |
48 |
> > |
49 |
> > A downside is that a kernel could be released that wont build on an |
50 |
> > arch. Does that imply failure of our QA process? Or is it acceptable, as |
51 |
> > a fix almost always follows right after that kind of situation. |
52 |
> > |
53 |
> This is fine. Within the space of all arches and all possible |
54 |
> configurations, kernels always have bugs. On vanilla-sources, these |
55 |
> reports should go directly upstream. If we have fixes, we should pass |
56 |
> them upstream. |
57 |
> |
58 |
> We should do a news item to alert users to the new policy. What is the |
59 |
> migration path to dropping stable keywords? Some users may sit on |
60 |
> stable kernels thinking that's where we are drawing the line of |
61 |
> stability, while we've actually dropped that distinction all together. |
62 |
|
63 |
You are 100% right on that. I've had users that refuse to upgrade |
64 |
kernels because they were not stabilized. This is definitely news item |
65 |
worthy. |
66 |
|
67 |
> |
68 |
> --Tony |
69 |
> |
70 |
> -- |
71 |
> Anthony G. Basile, Ph.D. |
72 |
> Gentoo Linux Developer [Hardened] |
73 |
> E-Mail : blueness@g.o |
74 |
> GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
75 |
> GnuPG ID : F52D4BBA |
76 |
> |
77 |
> |
78 |
|
79 |
-- |
80 |
Mike Pagano |
81 |
Gentoo Developer - Kernel Project |
82 |
Gentoo Sources - Lead |
83 |
E-Mail : mpagano@g.o |
84 |
GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 |
85 |
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index |