1 |
On Sat, Jun 22, 2013 at 02:02:59AM +0200, Tom Wijsman wrote: |
2 |
> On Fri, 21 Jun 2013 07:58:01 -0700 |
3 |
> Greg KH <gregkh@g.o> wrote: |
4 |
> |
5 |
> > I bumped the vanilla-kernel sources yesterday, and deleted some |
6 |
> > obsolete, and known-insecure versions at the same time (i.e. the 3.7 |
7 |
> > and 3.8 ebuilds.) |
8 |
> |
9 |
> Thank you for keeping an eye on them; I got into a habit of only |
10 |
> bumping gentoo-sources, so I don't always remind the to do vanilla, |
11 |
> I'll do my best to add it to the habbit in the future. |
12 |
> |
13 |
> > They were added back because they were the last releases marked |
14 |
> > "stable" for some arches. |
15 |
> |
16 |
> Yes, this is actively being checked to avoid that there is no stable |
17 |
> kernel present; if you don't want that to happen then you should make |
18 |
> an individual arrangement with the arch teams, such that they are aware |
19 |
> that the stabilization of this package is individually arranged. |
20 |
> |
21 |
> Since ago does stabilizations for multiple arches, is involved in |
22 |
> security bugs and did the restore on this particular package; I have |
23 |
> added him to CC so he is aware of this discussion going on. |
24 |
> |
25 |
> http://thread.gmane.org/gmane.linux.gentoo.kernel/697 |
26 |
> |
27 |
> > In thinking about this, that's totally wrong. Either all of these |
28 |
> > ebuilds are marked stable, or none are. And we should really NEVER |
29 |
> > have known buggy ebuilds marked stable for the vanilla kernels, as |
30 |
> > that's just dangerous on many different levels. |
31 |
> > |
32 |
> > So, should I just mark these always stable, or never stable? I don't |
33 |
> > think we should mix the two, as the previous versions are always known |
34 |
> > buggy, and have problems, and shouldn't be used. |
35 |
> |
36 |
> I think it may be a nice idea to have vanilla-sources reflect upstream; |
37 |
> that is, always stable and drop versions which are not. |
38 |
|
39 |
Great! But as only the latest version released is "stable", that's all |
40 |
that should stick around, right? |
41 |
|
42 |
> If possible we could script it to keep the package unstable the first X |
43 |
> days it is in Portage to keep the stabilization effect in place; that |
44 |
> way Gentoo users are unaffected if something goes wrong the day after |
45 |
> you push a patch, I assume not, but you never know. |
46 |
|
47 |
If something goes "wrong" the day after I push a update, I push a new |
48 |
one fixing the problem, so this shouldn't be an issue, right? |
49 |
|
50 |
And as these are coming out about 1-2 a week, the timeout before the |
51 |
arch teams could get around to marking things stable seems like a lot of |
52 |
work, for something that isn't really needed at all. |
53 |
|
54 |
thanks, |
55 |
|
56 |
greg k-h |