On Fri, Jun 21, 2013 at 03:36:12PM -0400, Mike Pagano wrote: > > > 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? > > This policy was put in place for the really "serious" security issues.
Who is making the judgement call about "serious"? And how do you know that problems aren't being fixed that aren't "serious"? > It was expected that the person from the kernel team can make the call > on whether auto stablizing is the way to go for a particular > vulnerability. Trying to track vunerabilities across kernel versions is going to be hard, especially for ones that are not public yet :) > We were trying to make us more agile when responding to serious root > exploits and not look like the distro that is not on top of these > things. I understand, and I think the work done on the "normal" kernel ebuilds are great this way. This is just for the vanilla kernels, they should track the upstream releases directly, no need for any Gentoo developer to make a judgement call on when something is "stable" or not, as again, there's nothing they can do about it. > > 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. > > I am not against either. And I think this is the way to go. (always > unstable). > > Let the user know that we always provide the latest kernel we can and > they need to always upgrade as you always suggest during upstream > releases. Great. > Users have a certain level of expectation and since no kernel version > can be considered vulnerability free for long maybe we do them a > disservice by giving them a false impression that a kernel version is > safe and stable. I totally agree. > I would ask others's on the team (or not on the team) to consider this idea. > > At some point we can pull straws and bring this to -dev. I can do this if no one else wants to, as I know a bit about how upstream works in this area :) thanks, greg k-h
