[gentoo-dev] Re: rfc: revisiting our stabilization policy

[Duncan]

Tom Wijsman posted on Wed, 15 Jan 2014 01:28:09 +0100 as excerpted:

>> Another option (and I don't mean to step on any toes or call anyone out
>> here, these are just examples) may be to just deprecate stabilizing
>> certain software. Packages such as the stuff in app-vim/ or app-emacs/
>> or some games or some scientific software. For the editor plugins, most
>> people do not get them from the package manager I feel and a Vim plugin
>> requires almost as much arch testing work as a new version of grep, for
>> example...
>
> Sounds like a good idea, but how do we translate that to the user;
> always mark them stable, or always mark them unstable? Do we want users
> to explicitly accept keywords on these packages?

As a ~arch/masked/overlay/live user here (who additionally doesn't even 
use gentoo kernel ebuilds, preferring direct upstream git and my own 
scripts), I haven't even checked if it actually happened (looks like 
gentoo-sources-3.10.x is still stable on x86/amd64, so maybe not), but...

There was previous discussion of destable-keywording the kernel.  How has 
that gone?

I've always thought that having a stable policy exception that the user 
actually has to deal with for certain packages, particularly core 
packages such as the kernel, would be confusing at best.  Still, given 
the upstream development pattern, I couldn't think of a reasonable 
alternative for the kernel, and agreed with the thread that it may have 
to be, for packages like that and perhaps google-chrome and firefox, 
where upstream releases are too close to 30-day and updates are very 
likely to be security-critical on packages that are net-exposed.

So it seemed it had to be, for them, and if that has gone well, perhaps 
expanding that no-stable policy precedent to things like editor plugins 
could work better than I might have imagined.

The other question then becomes, since ~arch packages are normally masked 
to stable, how are users exposed to them?  What about a file somewhere in 
profiles that lists all these no-stable packages, such that the PM can 
(perhaps optionally, I could imagine a setting in make.conf...) list all 
~arch versions of those packages on an otherwise stable system as if they 
were stable, tho possibly marked in some way to indicate that this 
package isn't a stable-keyword candidate?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman