1 |
On Fri, 21 Jun 2013 20:42:44 -0700 |
2 |
Greg KH <greg@×××××.com> wrote: |
3 |
|
4 |
> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote: |
5 |
> > On Fri, 21 Jun 2013 17:13:03 -0700 |
6 |
> > Greg KH <gregkh@g.o> wrote: |
7 |
> > |
8 |
> > > Great! But as only the latest version released is "stable", |
9 |
> > > that's all that should stick around, right? |
10 |
> > |
11 |
> > Tricky decision to make. Do we really want to force people's kernel |
12 |
> > sources to unmerge every single time you push a new version? Which |
13 |
> > on its own turn, forces them to build and install the new kernel. |
14 |
> |
15 |
> If they are following the vanilla kernels, isn't that what people |
16 |
> expect? The latest stable-kernel-of-the-week, as that's what I'm |
17 |
> releasing. They don't have to do an update if they don't want to :) |
18 |
|
19 |
If we don't keep around other ebuilds their sources will unexpectedly |
20 |
unmerge upon a dependency clean; they can only stop it if they see it |
21 |
in the list of packages that will be unmerged, and do something to |
22 |
specifically keep them. |
23 |
|
24 |
Feel free to experiment with this happening in your Portage tree. |
25 |
|
26 |
> > > > If possible we could script it to keep the package unstable the |
27 |
> > > > first X days it is in Portage to keep the stabilization effect |
28 |
> > > > in place; that way Gentoo users are unaffected if something |
29 |
> > > > goes wrong the day after you push a patch, I assume not, but |
30 |
> > > > you never know. |
31 |
> > > |
32 |
> > > If something goes "wrong" the day after I push a update, I push a |
33 |
> > > new one fixing the problem, so this shouldn't be an issue, right? |
34 |
> > |
35 |
> > It's not so much about fixing the problem, but rather about the |
36 |
> > severity of the issue. If this involves a corruption that corrupts a |
37 |
> > large amount of data on well known hardware which the patches were |
38 |
> > not tested on, users with such hardware would be affected; if we |
39 |
> > however delay our Gentoo users, they wouldn't become affected due |
40 |
> > to an upstream problem, unless they intentionally use the ~ |
41 |
> > keyword |
42 |
> |
43 |
> And how would you find out about these types of issues, unless they |
44 |
> get tested on those systems? It's a chicken-and-egg issue. People |
45 |
> who want more "stable" releases, follow the gentoo kernels. If you |
46 |
> want to track upstream directly, use the vanilla kernels, that's what |
47 |
> they are there for. |
48 |
|
49 |
Okay, I was just thinking through the possible scenarios of going with |
50 |
this approach; if nobody else reasonably objects we can do that. |
51 |
|
52 |
> > > And as these are coming out about 1-2 a week, the timeout before |
53 |
> > > the arch teams could get around to marking things stable seems |
54 |
> > > like a lot of work, for something that isn't really needed at all. |
55 |
> > |
56 |
> > What I meant was to not involve arch teams at all, as per the |
57 |
> > original proposal but just have a cron job running somewhere to |
58 |
> > stabilize the new versions, as well as to drop older versions. |
59 |
> |
60 |
> A cron job doesn't mean anything (how to stop it?), so you might as |
61 |
> well just always either mark them stable or not, as no one is testing |
62 |
> them for "stability". |
63 |
|
64 |
The cron job should not apply if the version is masked, had its |
65 |
keywords removed or the ebuild itself removed; this should be trivial |
66 |
to figure out through the Portage API. |
67 |
|
68 |
We do have people testing them for stability, as some people run a |
69 |
system with stable keywords whereas other people wan't to be more risky |
70 |
and use the unstable / testing / ... ~ keyword. |
71 |
|
72 |
> > On the other hand, the vanilla-sources ebuilds set |
73 |
> > K_SECURITY_UNSUPPORTED="1"; so perhaps we're not even aiming for the |
74 |
> > (professional) server people at all and therefore perhaps only the |
75 |
> > laptop and desktop users. Or at least, that's how Gentoo Security |
76 |
> > and that variable would make it look like; I agree though that it is |
77 |
> > inconsistent with how upstream would look at these versions, I |
78 |
> > therofore think it should be a good idea to reevaluate said |
79 |
> > variable if we are going to change the way we stabilize and drop |
80 |
> > vanilla-sources. |
81 |
> |
82 |
> I'll leave that alone, as I don't know what that flag means or does, |
83 |
> sorry. |
84 |
|
85 |
It prints out the following message, which becomes less the case if we |
86 |
stabilize it more; as you said, the kernel is more often released these |
87 |
days and therefore recent security issues are much faster dealt with. |
88 |
|
89 |
|
90 |
${PN} is UNSUPPORTED by Gentoo Security. |
91 |
This means that it is likely to be vulnerable to recent security issues. |
92 |
For specific information on why this kernel is unsupported, please read: |
93 |
http://www.gentoo.org/proj/en/security/kernel.xml |
94 |
|
95 |
|
96 |
PS: On a perhaps irrelevant side note, what I find interesting in the |
97 |
above URL is that it lists vanilla-sources as containing rc entries |
98 |
(which would be marked with the ~ keyword) and git-sources as |
99 |
containing daily snapshots; it appears that the rc entries have moved |
100 |
to git-sources and that git-sources no longer does daily snapshots. |
101 |
|
102 |
-- |
103 |
With kind regards, |
104 |
|
105 |
Tom Wijsman (TomWij) |
106 |
Gentoo Developer |
107 |
|
108 |
E-mail address : TomWij@g.o |
109 |
GPG Public Key : 6D34E57D |
110 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |