Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5093 bytes --]

On Fri, 21 Jun 2013 20:42:44 -0700
Greg KH <greg@kroah.com> wrote:

> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote:
> > On Fri, 21 Jun 2013 17:13:03 -0700
> > Greg KH <gregkh@gentoo.org> wrote:
> > 
> > > Great!  But as only the latest version released is "stable",
> > > that's all that should stick around, right?
> > 
> > Tricky decision to make. Do we really want to force people's kernel
> > sources to unmerge every single time you push a new version? Which
> > on its own turn, forces them to build and install the new kernel.
> 
> If they are following the vanilla kernels, isn't that what people
> expect?  The latest stable-kernel-of-the-week, as that's what I'm
> releasing.  They don't have to do an update if they don't want to :)

If we don't keep around other ebuilds their sources will unexpectedly
unmerge upon a dependency clean; they can only stop it if they see it
in the list of packages that will be unmerged, and do something to
specifically keep them.

Feel free to experiment with this happening in your Portage tree.
 
> > > > If possible we could script it to keep the package unstable the
> > > > first X days it is in Portage to keep the stabilization effect
> > > > in place; that way Gentoo users are unaffected if something
> > > > goes wrong the day after you push a patch, I assume not, but
> > > > you never know.
> > > 
> > > If something goes "wrong" the day after I push a update, I push a
> > > new one fixing the problem, so this shouldn't be an issue, right?
> > 
> > It's not so much about fixing the problem, but rather about the
> > severity of the issue. If this involves a corruption that corrupts a
> > large amount of data on well known hardware which the patches were
> > not tested on, users with such hardware would be affected; if we
> > however delay our Gentoo users, they wouldn't become affected due
> > to an upstream problem, unless they intentionally use the  ~
> > keyword
> 
> And how would you find out about these types of issues, unless they
> get tested on those systems?  It's a chicken-and-egg issue.  People
> who want more "stable" releases, follow the gentoo kernels.  If you
> want to track upstream directly, use the vanilla kernels, that's what
> they are there for.

Okay, I was just thinking through the possible scenarios of going with
this approach; if nobody else reasonably objects we can do that.

> > > And as these are coming out about 1-2 a week, the timeout before
> > > the arch teams could get around to marking things stable seems
> > > like a lot of work, for something that isn't really needed at all.
> > 
> > What I meant was to not involve arch teams at all, as per the
> > original proposal but just have a cron job running somewhere to
> > stabilize the new versions, as well as to drop older versions.
> 
> A cron job doesn't mean anything (how to stop it?), so you might as
> well just always either mark them stable or not, as no one is testing
> them for "stability".

The cron job should not apply if the version is masked, had its
keywords removed or the ebuild itself removed; this should be trivial
to figure out through the Portage API.

We do have people testing them for stability, as some people run a
system with stable keywords whereas other people wan't to be more risky
and use the unstable / testing / ...  ~  keyword.

> > On the other hand, the vanilla-sources ebuilds set
> > K_SECURITY_UNSUPPORTED="1"; so perhaps we're not even aiming for the
> > (professional) server people at all and therefore perhaps only the
> > laptop and desktop users. Or at least, that's how Gentoo Security
> > and that variable would make it look like; I agree though that it is
> > inconsistent with how upstream would look at these versions, I
> > therofore think it should be a good idea to reevaluate said
> > variable if we are going to change the way we stabilize and drop
> > vanilla-sources.
> 
> I'll leave that alone, as I don't know what that flag means or does,
> sorry.

It prints out the following message, which becomes less the case if we
stabilize it more; as you said, the kernel is more often released these
days and therefore recent security issues are much faster dealt with.


${PN} is UNSUPPORTED by Gentoo Security.
This means that it is likely to be vulnerable to recent security issues.
For specific information on why this kernel is unsupported, please read:
http://www.gentoo.org/proj/en/security/kernel.xml


PS: On a perhaps irrelevant side note, what I find interesting in the
above URL is that it lists vanilla-sources as containing rc entries
(which would be marked with the  ~  keyword) and git-sources as
containing daily snapshots; it appears that the rc entries have moved
to git-sources and that git-sources no longer does daily snapshots.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]