1 |
On Wed, 21 Aug 2013 13:42:56 +0400 |
2 |
Sergey Popov <pinkbyte@g.o> wrote: |
3 |
|
4 |
> So it is definitely NOT 7 weeks |
5 |
|
6 |
Let me clarify this again, our last stable kernel is from 7 weeks ago. |
7 |
|
8 |
> 21.08.2013 13:28, Tom Wijsman пишет: |
9 |
> > That is 3.10.7, not 3.10; please look into how kernel releases work, |
10 |
> > minor releases are merely a small number of "backported" "known" |
11 |
> > fixes. |
12 |
> > |
13 |
> > What you propose, waiting 30 days for a minor; simply doesn't work |
14 |
> > when there are one to two minors a week, it puts us even more |
15 |
> > behind... |
16 |
> > |
17 |
> |
18 |
> We considered stabilizing package relying on it's version. |
19 |
|
20 |
We consider that as well, and for all the past releases it worked out. |
21 |
|
22 |
> Policy says that we should wait reasonable amount of time, no matter |
23 |
> which version it is. |
24 |
|
25 |
It does not state anything about versions in the policy, AFAIK; please |
26 |
refer me to it, and also note that on top of that we have the permission |
27 |
from the arch teams to auto stable minor releases when necessary. |
28 |
|
29 |
> And yes, minor release MAY bring breakages, do not tell me that they |
30 |
> are not, i hit such breakages at least 4 times for kernel(no matter |
31 |
> gentoo or vanilla, so problem is NOT genpatches) for past 5 years. |
32 |
|
33 |
If you run ~, a breakage that you and some others experience less than |
34 |
once a year is to be expected; so, what you state here does not reflect |
35 |
our way of stabilization. In most of the cases, a later minor is better. |
36 |
|
37 |
> And do you really want to stabilize EVERY minor release of some |
38 |
> upstream stable branch? Maybe you want to bring some stable well |
39 |
> tested version for some period and let unstable users choose another |
40 |
> if they want to? And then - jump to next stable branch. |
41 |
|
42 |
No, what you propose is what we have been doing for a long while. |
43 |
|
44 |
> As i said early - it is not. Kernel team may have different policies |
45 |
> on stabilization, that's OK IMO, but do not bend facts. This is |
46 |
> release, and it should be considered as release, no matter minor or |
47 |
> major. And stabilizations counts from it, not from 3.10.0. Following |
48 |
> your logic i can say that KDE 4 is major release, and 4.1, 4.2 etc |
49 |
> are "minor". They are not. |
50 |
|
51 |
Okay, then feel free to propose which versions we should pick for |
52 |
stabilization? At which times? As you will see, it doesn't work out... |
53 |
|
54 |
The kernel releases are not to be confused with that of another |
55 |
package; if I take a look at KDE's 4.1 announcement [1] I see that it |
56 |
is a "feature release", which is not what a minor kernel release does. |
57 |
|
58 |
[1]: http://www.kde.org/announcements/4.1/ |
59 |
|
60 |
> >> If some open-source modules with active upstreams, included in |
61 |
> >> portage, do not support yet 3.10.* which will lead to unbootable |
62 |
> >> system for some stable users - what you should say? "Oops, sorry, |
63 |
> >> guys?" That's not how stable should work. |
64 |
> > |
65 |
> > That's how it has always worked, we do not see a need to change |
66 |
> > this. |
67 |
> |
68 |
> No it is not. We considered such things as serious flaws. At least - i |
69 |
> consider. |
70 |
|
71 |
So do I, but why should it block stabilization? |
72 |
|
73 |
Why do the stability and security of other users have to suffer by that? |
74 |
|
75 |
There are other ways to deal with this: |
76 |
|
77 |
- Keep nvidia-drivers unstable, though they likely don't want to. |
78 |
|
79 |
- Clearly state that they don't work together, users should read that; |
80 |
but well, do we really want to account for the users that don't read? |
81 |
|
82 |
- Dep block the packages, *ugh*, let's not do this if we don't need to. |
83 |
|
84 |
- ... |
85 |
|
86 |
> >> And as for security stabilization, if you |
87 |
> >> say that version bump BRINGS security fixes, you KNOW what they |
88 |
> >> are, and you do NOT file a security bug about old stable(and now - |
89 |
> >> vulnerable!) kernel on Gentoo bugzilla, then current stabilization |
90 |
> >> bug has no relation to security(as Gentoo Security team does not |
91 |
> >> know about security problems), period. |
92 |
> > |
93 |
> > Actually, those are constantly filed by ago; please look at the |
94 |
> > picture first before you describe it, because you are drawing |
95 |
> > assumptions here. |
96 |
> > |
97 |
> |
98 |
> I do not see any dependant bugs in your current stable request, but |
99 |
> you keep telling me about security, so i do not drawing any |
100 |
> assumptions - it is not security stabilization in terms of |
101 |
> Gentoo (probably it becomes so if you can find apropriate security |
102 |
> flaws). |
103 |
|
104 |
You do draw assumptions, because you don't take a look; please do: |
105 |
|
106 |
https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org |
107 |
|
108 |
Sort by "Changed" such that the newest appear on top. |
109 |
|
110 |
-- |
111 |
With kind regards, |
112 |
|
113 |
Tom Wijsman (TomWij) |
114 |
Gentoo Developer |
115 |
|
116 |
E-mail address : TomWij@g.o |
117 |
GPG Public Key : 6D34E57D |
118 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |