| 1 |
On Fri, Jun 21, 2013 at 11:30:56AM -0400, Mike Pagano wrote: |
| 2 |
> On Fri, Jun 21, 2013 at 07:58:01AM -0700, Greg KH wrote: |
| 3 |
> > Hi all, |
| 4 |
> > |
| 5 |
> > I bumped the vanilla-kernel sources yesterday, and deleted some |
| 6 |
> > obsolete, and known-insecure versions at the same time (i.e. the 3.7 and |
| 7 |
> > 3.8 ebuilds.) They were added back because they were the last releases |
| 8 |
> > marked "stable" for some arches. |
| 9 |
> > |
| 10 |
> > In thinking about this, that's totally wrong. Either all of these |
| 11 |
> > ebuilds are marked stable, or none are. And we should really NEVER have |
| 12 |
> > known buggy ebuilds marked stable for the vanilla kernels, as that's |
| 13 |
> > just dangerous on many different levels. |
| 14 |
> > |
| 15 |
> > So, should I just mark these always stable, or never stable? I don't |
| 16 |
> > think we should mix the two, as the previous versions are always known |
| 17 |
> > buggy, and have problems, and shouldn't be used. |
| 18 |
> > |
| 19 |
> > thanks, |
| 20 |
> > |
| 21 |
> > greg k-h |
| 22 |
> > |
| 23 |
> |
| 24 |
> |
| 25 |
> Hi, Greg, |
| 26 |
> |
| 27 |
> We hammered out a policy sometime in the past that if you add a new |
| 28 |
> version for the reasons you did and remove the stable ones (that have |
| 29 |
> security issues) you can do an auto stable. |
| 30 |
|
| 31 |
Where was that hammered out? On this list? |
| 32 |
|
| 33 |
> I have not gone through the commit log to see what happened but here is |
| 34 |
> an easy example. |
| 35 |
> |
| 36 |
> You know the stable version 3.8.4 has a sec bug. |
| 37 |
> You have a minor point release that fixes this. |
| 38 |
> |
| 39 |
> You remove 3.8.4, add 3.8.5 and auto stable for any arch that had a |
| 40 |
> stable keyword for 3.8.4. |
| 41 |
> |
| 42 |
> This should be written down and if it's not that's probably on me as I |
| 43 |
> am the only kernel person (i think) that was involved in the decision |
| 44 |
> and is still around. |
| 45 |
|
| 46 |
But every single stable kernel release I make fixes bugs that some might |
| 47 |
consider "security" issues. So that means that every single stable |
| 48 |
release should be marked stable, right? |
| 49 |
|
| 50 |
We should _never_ have an end-of-life kernel marked stable, that's just |
| 51 |
asking for trouble. |
| 52 |
|
| 53 |
> P.S. if 3.8.4 is bad, and we have to go to 3.9 we ask for a quick |
| 54 |
> "emergency" stabilization effort by the arch teams. |
| 55 |
> |
| 56 |
> Let me know if that is clear as mud. |
| 57 |
|
| 58 |
It's clear, but I feel incorrect :) |
| 59 |
|
| 60 |
As we can't do anything to these releases to fix problems or "make them |
| 61 |
more stable", they should either always be unstable, or always be |
| 62 |
stable, there is no difference. |
| 63 |
|
| 64 |
thanks, |
| 65 |
|
| 66 |
greg k-h |
Archives