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 22:44:40 -0800
From:	"Luis R. Rodriguez" <mcgrof@...il.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	wireless <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: Elaboration on "Equivalent fix must already exist in Linus' tree"

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.

Let me try:

Our "equivalent fix" policy exists to ensure the next kernel release
doesn't suck more, only less. We do this by ensuring every single
patch that goes into any stable kernel is already applied on the tree
used to release the next kernel release. As an consequence of this
policy we also tend to create more exposure and create better focus to
the different development trees that lead to Linus's tree thereby
making the distributed development model we depend on more apparent
and better structured.

  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/