Gentoo Archives: gentoo-dev

From: Sergey Popov <pinkbyte@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: stabilization policies
Date: Wed, 21 Aug 2013 09:44:48
Message-Id: 52148BA0.7020308@gentoo.org
In Reply to: Re: [gentoo-dev] rfc: stabilization policies by Tom Wijsman
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] rfc: stabilization policies Tom Wijsman <TomWij@g.o>