Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: gentoo-dev@l.g.o
Cc: pinkbyte@g.o
Subject: Re: [gentoo-dev] rfc: stabilization policies
Date: Wed, 21 Aug 2013 09:28:47
Message-Id: 20130821112834.114fbc61@TOMWIJ-GENTOO
In Reply to: Re: [gentoo-dev] rfc: stabilization policies by Sergey Popov
1 On Wed, 21 Aug 2013 12:46:17 +0400
2 Sergey Popov <pinkbyte@g.o> wrote:
3
4 > 21.08.2013 12:25, Tom Wijsman пишет:
5 > >
6 > > 3.10 is not a shiny new version, it has been in the Portage tree
7 > > for 7 weeks now (upstream release at 2013-06-30 22:13:42 (GMT));
8 > > so, that's almost double the time you are suggesting.
9 > >
10 >
11 > Current stabilization target(3.10.7) was added to tree:
12 >
13 > *gentoo-sources-3.10.7 (15 Aug 2013)
14 >
15 > 15 Aug 2013; Tom Wijsman <TomWij@g.o>
16 > +gentoo-sources-3.0.91.ebuild,
17 > +gentoo-sources-3.10.7.ebuild, +gentoo-sources-3.4.58.ebuild,
18 > -gentoo-sources-3.0.87.ebuild, -gentoo-sources-3.10.4.ebuild,
19 > -gentoo-sources-3.10.5-r1.ebuild, -gentoo-sources-3.10.6.ebuild,
20 > -gentoo-sources-3.4.54.ebuild:
21 > Version bumps 3.0.91, 3.4.58 and 3.10.7. Removed old. (skip)
22 >
23 >
24 > So it is definitely NOT 7 weeks(30 days period counting from time when
25 > ordinary user can install it through portage, thus - after hitting
26 > portage tree). You know, that we can lighten stabilization
27 > requirements of 30 days sometimes, but let's be honest.
28
29 That is 3.10.7, not 3.10; please look into how kernel releases work,
30 minor releases are merely a small number of "backported" "known" fixes.
31
32 What you propose, waiting 30 days for a minor; simply doesn't work
33 when there are one to two minors a week, it puts us even more behind...
34
35 > > Why should an external proprietary module that does not fix what is
36 > > broken for 7 weeks now block stabilization; it has never blocked
37 > > stabilization before, and I do not see a reason it should now...
38 > >
39 > >> And that fact, that you can successfully build and run kernel for a
40 > >> couple of hours, does not make it "good, well tested stable
41 > >> candidate"
42 > >
43 > > Having people run it for 7 weeks is not a couple of hours.
44 > >
45 >
46 > First of all, as i said early - it is NOT 7 weeks(thus - not a couple
47 > of hours either).
48
49 It is 7 weeks.
50
51 > And example with Nvidia drivers is not point of beginning a flamewar.
52 > We ARE a distro. Then, we should propose INTEGRATION of some kind.
53
54 Well, by bringing it up on the ML it will become one; I'm simply not
55 interested in this, decisions were taken a very long time ago anyway.
56
57 > If some open-source modules with active upstreams, included in
58 > portage, do not support yet 3.10.* which will lead to unbootable
59 > system for some stable users - what you should say? "Oops, sorry,
60 > guys?" That's not how stable should work.
61
62 That's how it has always worked, we do not see a need to change this.
63
64 > We should either mark such modules as forever unstable (or even
65 > mask?), saying "guys, shit happens, do not use this in Gentoo, unless
66 > you are dead sure, that you can handle problems with updates" or
67 > slowing down stabilization(i am not talking about security
68 > stabilization right now).
69
70 Tell them, I am interested if this will cause a change; I guess not...
71
72 > And as for security stabilization, if you
73 > say that version bump BRINGS security fixes, you KNOW what they are,
74 > and you do NOT file a security bug about old stable(and now -
75 > vulnerable!) kernel on Gentoo bugzilla, then current stabilization
76 > bug has no relation to security(as Gentoo Security team does not know
77 > about security problems), period.
78
79 Actually, those are constantly filed by ago; please look at the picture
80 first before you describe it, because you are drawing assumptions here.
81
82 > > Well, my thoughts is that the way we are doing it now we aren't
83 > > going to be able to deal with the lack of resources; so, a
84 > > different approach is necessary and I don't see how it is "old, but
85 > > also breakable"...
86 > >
87 >
88 > I undestand your disturbance as Gentoo Kernel team member. But your
89 > proposal does not seem good to me.
90
91 There is not a proposal in that quote; and through this thread, I and
92 others have made multiple proposals, I'm not sure what you refer to...
93
94 --
95 With kind regards,
96
97 Tom Wijsman (TomWij)
98 Gentoo Developer
99
100 E-mail address : TomWij@g.o
101 GPG Public Key : 6D34E57D
102 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

Attachments

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

Replies

Subject Author
Re: [gentoo-dev] rfc: stabilization policies Sergey Popov <pinkbyte@g.o>