1 |
21.08.2013 13:28, Tom Wijsman пишет: |
2 |
> That is 3.10.7, not 3.10; please look into how kernel releases work, |
3 |
> minor releases are merely a small number of "backported" "known" fixes. |
4 |
> |
5 |
> What you propose, waiting 30 days for a minor; simply doesn't work |
6 |
> when there are one to two minors a week, it puts us even more behind... |
7 |
> |
8 |
|
9 |
We considered stabilizing package relying on it's version. Policy says |
10 |
that we should wait reasonable amount of time, no matter which version |
11 |
it is. And yes, minor release MAY bring breakages, do not tell me that |
12 |
they are not, i hit such breakages at least 4 times for kernel(no matter |
13 |
gentoo or vanilla, so problem is NOT genpatches) for past 5 years. |
14 |
|
15 |
And do you really want to stabilize EVERY minor release of some upstream |
16 |
stable branch? Maybe you want to bring some stable well tested version |
17 |
for some period and let unstable users choose another if they want to? |
18 |
And then - jump to next stable branch. |
19 |
|
20 |
>>> Why should an external proprietary module that does not fix what is |
21 |
>>> broken for 7 weeks now block stabilization; it has never blocked |
22 |
>>> stabilization before, and I do not see a reason it should now... |
23 |
>>> |
24 |
>>>> And that fact, that you can successfully build and run kernel for a |
25 |
>>>> couple of hours, does not make it "good, well tested stable |
26 |
>>>> candidate" |
27 |
>>> |
28 |
>>> Having people run it for 7 weeks is not a couple of hours. |
29 |
>>> |
30 |
>> |
31 |
>> First of all, as i said early - it is NOT 7 weeks(thus - not a couple |
32 |
>> of hours either). |
33 |
> |
34 |
> It is 7 weeks. |
35 |
|
36 |
As i said early - it is not. Kernel team may have different policies on |
37 |
stabilization, that's OK IMO, but do not bend facts. This is release, |
38 |
and it should be considered as release, no matter minor or major. And |
39 |
stabilizations counts from it, not from 3.10.0. Following your logic i |
40 |
can say that KDE 4 is major release, and 4.1, 4.2 etc are "minor". They |
41 |
are not. |
42 |
|
43 |
>> If some open-source modules with active upstreams, included in |
44 |
>> portage, do not support yet 3.10.* which will lead to unbootable |
45 |
>> system for some stable users - what you should say? "Oops, sorry, |
46 |
>> guys?" That's not how stable should work. |
47 |
> |
48 |
> That's how it has always worked, we do not see a need to change this. |
49 |
|
50 |
No it is not. We considered such things as serious flaws. At least - i |
51 |
consider. |
52 |
|
53 |
>> And as for security stabilization, if you |
54 |
>> say that version bump BRINGS security fixes, you KNOW what they are, |
55 |
>> and you do NOT file a security bug about old stable(and now - |
56 |
>> vulnerable!) kernel on Gentoo bugzilla, then current stabilization |
57 |
>> bug has no relation to security(as Gentoo Security team does not know |
58 |
>> about security problems), period. |
59 |
> |
60 |
> Actually, those are constantly filed by ago; please look at the picture |
61 |
> first before you describe it, because you are drawing assumptions here. |
62 |
> |
63 |
|
64 |
I do not see any dependant bugs in your current stable request, but you |
65 |
keep telling me about security, so i do not drawing any assumptions - it |
66 |
is not security stabilization in terms of Gentoo(probably it becomes so |
67 |
if you can find apropriate security flaws). |
68 |
|
69 |
-- |
70 |
Best regards, Sergey Popov |
71 |
Gentoo developer |
72 |
Gentoo Desktop Effects project lead |
73 |
Gentoo Qt project lead |
74 |
Gentoo Proxy maintainers project lead |