On Mon, Mar 2, 2009 at 11:42 PM, <david@xxxxxxx> wrote:
> - Show quoted text -
> On Mon, 2 Mar 2009, Luis R. Rodriguez wrote:
>
>> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <greg@xxxxxxxxx> wrote:
>>>
>>> - Show quoted text -
>>> On Mon, Mar 02, 2009 at 10:44:40PM -0800, Luis R. Rodriguez wrote:
>>>>
>>>> On Mon, Mar 2, 2009 at 9:57 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
>>>>>
>>>>> Luis R. Rodriguez wrote:
>>>>>>
>>>>>> While extending the documentation for submitting Linux wireless bug
>>>>>> reports [1] we note the stable series policy on patches -- that of
>>>>>> having an equivalent fix already in Linus' tree. I find this
>>>>>> documented in Documentation/stable_kernel_rules.txt but I'm curious if
>>>>>> there is any other resource which documents this or elaborates on this
>>>>>> a bit more. I often tell people about this rule or push _really_ hard
>>>>>> on testing "upstream" but some people tend to not understand. I think
>>>>>> that elaborating a little on this can help and will hopefully create
>>>>>> more awareness around the importance of trees like Stephen's
>>>>>> linux-next tree.
>>>>>
>>>>> Just have people google for GregKH's copious messages, telling people a
>>>>> fix
>>>>> needs to be upstream before it goes into -stable.
>>>>>
>>>>> Typically you make things easy by emailing stable@xxxxxxxxxx with a
>>>>> commit
>>>>> id.
>>>>>
>>>>> There are only two exceptions:
>>>>> * fix is upstream, but needs to be modified for -stable
>>>>> * fix is not needed at all in upstream, but -stable still needs it
>>>>
>>>> This certainly helps, I'm also looking for good arguments to support
>>>> the reasoning behind the policy so that not only will people follow
>>>> this to help development but _understand_ it and so that they can
>>>> themselves promote things like linux-next and realize why its so
>>>> important. Mind you -- upstream for us in wireless for example is not
>>>> Linus its John's tree so what we promote is not to get the fix first
>>>> into Linus' tree but first into John's tree. Which is obvious to
>>>> developers but perhaps not to others.
>>>
>>> Who are these "people" that you are trying to convince?
>>
>> OK small silly example is convincing distributions it may be a good
>> idea to carry linux-next kernel packages as options to users to
>> hopefully down the road reduce the delta between what they carry and
>> what is actually upstream.
>
> linux-next is a testing tree for developers, it changes day to day, doesn't
> contain all relavent changes, and is definantly _not_ something that distros
> should be pushing to users.
Why not? Just as people may want to get bleeding edge wireless I don't
see why a user may not want to simply get bleeding edge wireless and
bleeding edge audio, and video. The latest RC series helps but lets
face it there are also a lot of good stuff queued for the -next
releases as well. The way I'm seeing this is if a user has no support
for a device on their system it should look something like this:
Distribution kernel -->
Distribution next stable kernel release (2.6.27 --> 2.6.28) -->
Distribution RC kernel (if one is available) | kernel.org RC kernel -->
Development tree kernel for a specific device -->
Staging
If the have multiple devices which are not yet supported by the latest
RC kernel but on -next then you have little options but I think a
concrete one should exist and it does.
>> Heh.. Maybe I expect too much of people and things.
>
> I think you are misunderstanding linux-next and how it relates to users and
> distros.
Probably if the above is not something a user may not actually want to test.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
