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