Gentoo Archives: gentoo-dev

From: Tom Wijsman <TomWij@g.o>
To: 1i5t5.duncan@×××.net
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Date: Thu, 16 Jan 2014 00:24:42
Message-Id: 20140116012334.143de474@TOMWIJ-GENTOO
In Reply to: [gentoo-dev] Re: rfc: revisiting our stabilization policy by Duncan <1i5t5.duncan@cox.net>
1 On Wed, 15 Jan 2014 23:59:49 +0000 (UTC)
2 Duncan <1i5t5.duncan@×××.net> wrote:
3
4 > There was previous discussion of destable-keywording the kernel. How
5 > has that gone?
6
7 That was for vanilla-sources only, because that has restricted to only
8 the latest upstream version; as that makes the version change almost
9 weekly, the package can't undergo our stabilization procedure.
10
11 > I've always thought that having a stable policy exception that the
12 > user actually has to deal with for certain packages, particularly
13 > core packages such as the kernel, would be confusing at best.
14
15 Yes, if this would ever happen to gentoo-sources; I'd think the
16 handbook would then need to be updated to mention the necessary extra
17 step, but I think it is not bound to happen any time soon.
18
19 > Still,
20 > given the upstream development pattern, I couldn't think of a
21 > reasonable alternative for the kernel, and agreed with the thread
22 > that it may have to be, for packages like that and perhaps
23 > google-chrome and firefox, where upstream releases are too close to
24 > 30-day and updates are very likely to be security-critical on
25 > packages that are net-exposed.
26
27 What we do now appears to work fine, critical security bugs cause fast
28 track stabilization if needed; I've backported some security fixes in
29 the past for less critical CVEs in the past, but the main problem here
30 for keeping this up is the lack of manpower on the kernel team.
31
32 > So it seemed it had to be, for them, and if that has gone well,
33 > perhaps expanding that no-stable policy precedent to things like
34 > editor plugins could work better than I might have imagined.
35
36 I think it needs to put the accept keywords in a more prominent place
37 if we're going to do this at a wider scale; currently it's in one of
38 those sections that people often don't read due to focusing on
39 continuing with there install instead, eg. they move to some DE guide.
40
41 > The other question then becomes, since ~arch packages are normally
42 > masked to stable, how are users exposed to them?
43
44 They aren't unless they accept keywords for them; which can either be
45 done globally using package.accept_keywords, or locally
46 by listing the package atom in /etc/portage/package.accept_keywords
47
48 > What about a file
49 > somewhere in profiles that lists all these no-stable packages, such
50 > that the PM can (perhaps optionally, I could imagine a setting in
51 > make.conf...) list all ~arch versions of those packages on an
52 > otherwise stable system as if they were stable, tho possibly marked
53 > in some way to indicate that this package isn't a stable-keyword
54 > candidate?
55
56 If we drop stable versions on a wider scale, we could indeed make the
57 ~arch versions more visible where they currently aren't; we don't want
58 to give the impression that we are removing everything.
59
60 --
61 With kind regards,
62
63 Tom Wijsman (TomWij)
64 Gentoo Developer
65
66 E-mail address : TomWij@g.o
67 GPG Public Key : 6D34E57D
68 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

Attachments

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