From: "Luis R. Rodriguez" <mcgrof@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: wireless <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Greg KH <greg@kroah.com>
Subject: Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
Date: Mon, 2 Mar 2009 22:44:40 -0800 [thread overview]
Message-ID: <43e72e890903022244j2b2f4276lf6e318f3dad3df@mail.gmail.com> (raw)
In-Reply-To: <49ACC6B0.409@garzik.org>
On Mon, Mar 2, 2009 at 9:57 PM, Jeff Garzik <jeff@garzik.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@kernel.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
next prev parent reply other threads:[~2009-03-03 6:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-03 5:43 Luis R. Rodriguez
2009-03-03 5:57 ` Jeff Garzik
2009-03-03 6:44 ` Luis R. Rodriguez [this message]
2009-03-03 7:20 ` Jeff Garzik
2009-03-03 7:26 ` Greg KH
2009-03-03 7:37 ` Luis R. Rodriguez
2009-03-03 7:42 ` david
2009-03-03 7:57 ` Luis R. Rodriguez
2009-03-03 9:16 ` Theodore Tso
2009-03-03 15:19 ` Stefan Richter
2009-03-03 14:53 ` Greg KH
2009-03-03 15:27 ` Stefan Richter
2009-03-03 17:23 ` Luis R. Rodriguez
2009-03-03 18:13 ` Stefan Richter
2009-03-03 18:43 ` Luis R. Rodriguez
2009-03-03 22:55 ` david
2009-03-03 6:27 ` Greg KH
2009-03-03 14:43 ` John W. Linville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43e72e890903022244j2b2f4276lf6e318f3dad3df@mail.gmail.com \
--to=mcgrof@gmail.com \
--cc=greg@kroah.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®