* [gentoo-dev] Re: rfc: revisiting our stabilization policy
@ 2014-01-15 23:59 99% ` Duncan
0 siblings, 0 replies; 1+ results
From: Duncan @ 2014-01-15 23:59 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-01-14 21:37 [gentoo-dev] rfc: revisiting our stabilization policy William Hubbs
2014-01-14 21:57 ` Michael Orlitzky
2014-01-14 22:33 ` William Hubbs
2014-01-14 22:43 ` Michael Orlitzky
2014-01-14 23:11 ` William Hubbs
2014-01-14 23:22 ` Jeff Horelick
2014-01-15 0:28 ` Tom Wijsman
2014-01-15 23:59 99% ` [gentoo-dev] " Duncan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox