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 <[email protected]> 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 <[email protected]> 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 : [email protected] > 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 : [email protected] 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
