Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: rfc: revisiting our stabilization policy
Date: Thu, 16 Jan 2014 00:00:39
Message-Id: pan$b73d0$b64504f5$fe4fae52$
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Tom Wijsman
1 Tom Wijsman posted on Wed, 15 Jan 2014 01:28:09 +0100 as excerpted:
3 >> Another option (and I don't mean to step on any toes or call anyone out
4 >> here, these are just examples) may be to just deprecate stabilizing
5 >> certain software. Packages such as the stuff in app-vim/ or app-emacs/
6 >> or some games or some scientific software. For the editor plugins, most
7 >> people do not get them from the package manager I feel and a Vim plugin
8 >> requires almost as much arch testing work as a new version of grep, for
9 >> example...
10 >
11 > Sounds like a good idea, but how do we translate that to the user;
12 > always mark them stable, or always mark them unstable? Do we want users
13 > to explicitly accept keywords on these packages?
15 As a ~arch/masked/overlay/live user here (who additionally doesn't even
16 use gentoo kernel ebuilds, preferring direct upstream git and my own
17 scripts), I haven't even checked if it actually happened (looks like
18 gentoo-sources-3.10.x is still stable on x86/amd64, so maybe not), but...
20 There was previous discussion of destable-keywording the kernel. How has
21 that gone?
23 I've always thought that having a stable policy exception that the user
24 actually has to deal with for certain packages, particularly core
25 packages such as the kernel, would be confusing at best. Still, given
26 the upstream development pattern, I couldn't think of a reasonable
27 alternative for the kernel, and agreed with the thread that it may have
28 to be, for packages like that and perhaps google-chrome and firefox,
29 where upstream releases are too close to 30-day and updates are very
30 likely to be security-critical on packages that are net-exposed.
32 So it seemed it had to be, for them, and if that has gone well, perhaps
33 expanding that no-stable policy precedent to things like editor plugins
34 could work better than I might have imagined.
36 The other question then becomes, since ~arch packages are normally masked
37 to stable, how are users exposed to them? What about a file somewhere in
38 profiles that lists all these no-stable packages, such that the PM can
39 (perhaps optionally, I could imagine a setting in make.conf...) list all
40 ~arch versions of those packages on an otherwise stable system as if they
41 were stable, tho possibly marked in some way to indicate that this
42 package isn't a stable-keyword candidate?
44 --
45 Duncan - List replies preferred. No HTML msgs.
46 "Every nonfree program has a lord, a master --
47 and if you use the program, he is your master." Richard Stallman


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