| 1 |
On 06/27/2013 03:45 PM, Mike Pagano wrote: |
| 2 |
> On Mon, Jun 24, 2013 at 09:27:10AM -0700, Greg KH wrote: |
| 3 |
>> On Sat, Jun 22, 2013 at 08:45:25AM +0200, Tom Wijsman wrote: |
| 4 |
>>> On Fri, 21 Jun 2013 20:42:44 -0700 |
| 5 |
>>> Greg KH <greg@×××××.com> wrote: |
| 6 |
>>> |
| 7 |
>>>> On Sat, Jun 22, 2013 at 02:45:16AM +0200, Tom Wijsman wrote: |
| 8 |
>>>>> On Fri, 21 Jun 2013 17:13:03 -0700 |
| 9 |
>>>>> Greg KH <gregkh@g.o> wrote: |
| 10 |
>>>>> |
| 11 |
>>>>>> Great! But as only the latest version released is "stable", |
| 12 |
>>>>>> that's all that should stick around, right? |
| 13 |
>>>>> Tricky decision to make. Do we really want to force people's kernel |
| 14 |
>>>>> sources to unmerge every single time you push a new version? Which |
| 15 |
>>>>> on its own turn, forces them to build and install the new kernel. |
| 16 |
>>>> If they are following the vanilla kernels, isn't that what people |
| 17 |
>>>> expect? The latest stable-kernel-of-the-week, as that's what I'm |
| 18 |
>>>> releasing. They don't have to do an update if they don't want to :) |
| 19 |
>>> If we don't keep around other ebuilds their sources will unexpectedly |
| 20 |
>>> unmerge upon a dependency clean; they can only stop it if they see it |
| 21 |
>>> in the list of packages that will be unmerged, and do something to |
| 22 |
>>> specifically keep them. |
| 23 |
>> True, so we can keep around 3-4 older ebuilds if needed, per kernel |
| 24 |
>> release. But who really does a dependency clean these days, I've never |
| 25 |
>> done one :) |
| 26 |
>> |
| 27 |
>> So, what's the next step? Should I announce the change to -dev? Anyone |
| 28 |
>> else really object to it? Other thoughts? |
| 29 |
>> |
| 30 |
>> thanks, |
| 31 |
>> |
| 32 |
>> greg k-h |
| 33 |
>> |
| 34 |
> Are we agreed on a few facts? |
| 35 |
> |
| 36 |
> 1. Upstream release rate is now a much higher 1-2 kernels a week. |
| 37 |
> 2. Very frequently, these releases contain security fixes. |
| 38 |
> 3. This rate of release puts arch teams in a difficult position, since |
| 39 |
> it is unsustainable to try to keep up tp date with stabilization |
| 40 |
> 4. By continuing the policy of providing a stable kernel version, Gentoo |
| 41 |
> is giving a false sense of security to its users, since by the time the |
| 42 |
> kernel does get stabilized, a newer version more with more security |
| 43 |
> fixes is almost always already released. |
| 44 |
> |
| 45 |
> Auto stabling keywords again will give that false impression of Gentoo |
| 46 |
> QA on a particular arch, so I don't think I would want that. |
| 47 |
> |
| 48 |
> A downside is that a kernel could be released that wont build on an |
| 49 |
> arch. Does that imply failure of our QA process? Or is it acceptable, as |
| 50 |
> a fix almost always follows right after that kind of situation. |
| 51 |
> |
| 52 |
This is fine. Within the space of all arches and all possible |
| 53 |
configurations, kernels always have bugs. On vanilla-sources, these |
| 54 |
reports should go directly upstream. If we have fixes, we should pass |
| 55 |
them upstream. |
| 56 |
|
| 57 |
We should do a news item to alert users to the new policy. What is the |
| 58 |
migration path to dropping stable keywords? Some users may sit on |
| 59 |
stable kernels thinking that's where we are drawing the line of |
| 60 |
stability, while we've actually dropped that distinction all together. |
| 61 |
|
| 62 |
--Tony |
| 63 |
|
| 64 |
-- |
| 65 |
Anthony G. Basile, Ph.D. |
| 66 |
Gentoo Linux Developer [Hardened] |
| 67 |
E-Mail : blueness@g.o |
| 68 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 69 |
GnuPG ID : F52D4BBA |
Archives