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

[Mike Pagano <mpagano@gentoo.org>]

On Thu, Jun 27, 2013 at 04:03:51PM -0400, Anthony G. Basile wrote:
> On 06/27/2013 03:45 PM, Mike Pagano wrote:
> > On Mon, Jun 24, 2013 at 09:27:10AM -0700, Greg KH wrote:
> >> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote:
> >>> 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.
> >> True, so we can keep around 3-4 older ebuilds if needed, per kernel
> >> release.  But who really does a dependency clean these days, I've never
> >> done one :)
> >>
> >> So, what's the next step?  Should I announce the change to -dev?  Anyone
> >> else really object to it?  Other thoughts?
> >>
> >> thanks,
> >>
> >> greg k-h
> >>
> > Are we agreed on a few facts?
> >
> > 1. Upstream release rate is now a much higher 1-2 kernels a week.
> > 2. Very frequently, these releases contain security fixes.
> > 3. This rate of release puts arch teams in a difficult position, since
> > it is unsustainable to try to keep up tp date with stabilization
> > 4. By continuing the policy of providing a stable kernel version, Gentoo
> > is giving a false sense of security to its users, since by the time the
> > kernel does get stabilized, a newer version more with more security
> > fixes is almost always already released.
> >
> > Auto stabling keywords again will give that false impression of Gentoo
> > QA on a particular arch, so I don't think I would want that.
> >
> > A downside is that a kernel could be released that wont build on an
> > arch. Does that imply failure of our QA process? Or is it acceptable, as
> > a fix almost always follows right after that kind of situation.
> >
> This is fine.  Within the space of all arches and all possible 
> configurations, kernels always have bugs.  On vanilla-sources, these 
> reports should go directly upstream.  If we have fixes, we should pass 
> them upstream.
> 
> We should do a news item to alert users to the new policy.  What is the 
> migration path to dropping stable keywords?  Some users may sit on 
> stable kernels thinking that's where we are drawing the line of 
> stability, while we've actually dropped that distinction all together.

You are 100% right on that. I've had users that refuse to upgrade
kernels because they were not stabilized. This is definitely news item
worthy.

> 
> --Tony
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail    : blueness@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 
> 

-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail     : mpagano@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index