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

[Greg KH]

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@g.o> 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 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.

> > 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 delayed stabilization and delayed dropping from the tree are merely
> ideas that I think are in favor of the users; I may be wrong about this
> but would like to at least see this discussed, unless everyone agrees
> we should completely reflect the current state as listed on kernel.org.
>
> As you probably know, there are different groups of users where some
> run personal laptops or desktops whereas other run a (professional)
> server. I think an approach that what would make sense for people
> running a secure and stable server might not necessarily make sense for
> people running their own laptop or desktop. Not all exploits target
> both servers and desktops (eg. they can't get behind router).

I agree, that's why we have so many different kernel packages.

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

greg k-h