On Fri, Jun 21, 2013 at 11:30:56AM -0400, Mike Pagano wrote: > On Fri, Jun 21, 2013 at 07:58:01AM -0700, Greg KH wrote: > > Hi all, > > > > I bumped the vanilla-kernel sources yesterday, and deleted some > > obsolete, and known-insecure versions at the same time (i.e. the 3.7 and > > 3.8 ebuilds.) They were added back because they were the last releases > > marked "stable" for some arches. > > > > In thinking about this, that's totally wrong. Either all of these > > ebuilds are marked stable, or none are. And we should really NEVER have > > known buggy ebuilds marked stable for the vanilla kernels, as that's > > just dangerous on many different levels. > > > > So, should I just mark these always stable, or never stable? I don't > > think we should mix the two, as the previous versions are always known > > buggy, and have problems, and shouldn't be used. > > > > thanks, > > > > greg k-h > > > > > Hi, Greg, > > We hammered out a policy sometime in the past that if you add a new > version for the reasons you did and remove the stable ones (that have > security issues) you can do an auto stable.
Where was that hammered out? On this list? > I have not gone through the commit log to see what happened but here is > an easy example. > > You know the stable version 3.8.4 has a sec bug. > You have a minor point release that fixes this. > > You remove 3.8.4, add 3.8.5 and auto stable for any arch that had a > stable keyword for 3.8.4. > > This should be written down and if it's not that's probably on me as I > am the only kernel person (i think) that was involved in the decision > and is still around. But every single stable kernel release I make fixes bugs that some might consider "security" issues. So that means that every single stable release should be marked stable, right? We should _never_ have an end-of-life kernel marked stable, that's just asking for trouble. > P.S. if 3.8.4 is bad, and we have to go to 3.9 we ask for a quick > "emergency" stabilization effort by the arch teams. > > Let me know if that is clear as mud. It's clear, but I feel incorrect :) As we can't do anything to these releases to fix problems or "make them more stable", they should either always be unstable, or always be stable, there is no difference. thanks, greg k-h
