On Wed, 15 Jan 2014 23:59:49 +0000 (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

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

That was for vanilla-sources only, because that has restricted to only
the latest upstream version; as that makes the version change almost
weekly, the package can't undergo our stabilization procedure.
 
> 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.

Yes, if this would ever happen to gentoo-sources; I'd think the
handbook would then need to be updated to mention the necessary extra
step, but I think it is not bound to happen any time soon.

> 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.

What we do now appears to work fine, critical security bugs cause fast
track stabilization if needed; I've backported some security fixes in
the past for less critical CVEs in the past, but the main problem here
for keeping this up is the lack of manpower on the kernel team.

> 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.

I think it needs to put the accept keywords in a more prominent place
if we're going to do this at a wider scale; currently it's in one of
those sections that people often don't read due to focusing on
continuing with there install instead, eg. they move to some DE guide.

> The other question then becomes, since ~arch packages are normally
> masked to stable, how are users exposed to them?

They aren't unless they accept keywords for them; which can either be
done globally using package.accept_keywords, or locally
by listing the package atom in /etc/portage/package.accept_keywords

> 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?

If we drop stable versions on a wider scale, we could indeed make the
~arch versions more visible where they currently aren't; we don't want
to give the impression that we are removing everything.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Attachment: signature.asc
Description: PGP signature

Reply via email to