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
| ||
|
Date: Tue, 03 Mar 2009 02:20:05 -0500 From: Jeff Garzik <jeff@...zik.org> To: "Luis R. Rodriguez" <mcgrof@...il.com> 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" 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. > > 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. Or more simply "so that fixes don't get lost" :) -stable is effectively a dead-end side branch, not the main trunk. Jeff -- 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/
Powered by blists - more mailing lists