linux-kernel - Re: Elaboration on "Equivalent fix must already exist in Linus' tree"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Mar 2009 23:57:23 -0800
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	david@...g.hm
Cc:	Greg KH <greg@...ah.com>, Jeff Garzik <jeff@...zik.org>,
	wireless <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Elaboration on "Equivalent fix must already exist in Linus' tree"

On Mon, Mar 2, 2009 at 11:42 PM,  <david@...g.hm> 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@...ah.com> 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@...zik.org> 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@...nel.org 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/