* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
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 14:53 ` Greg KH
2009-03-03 15:27 ` Stefan Richter
2 siblings, 1 reply; 18+ messages in thread
From: david @ 2009-03-03 7:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Greg KH, Jeff Garzik, wireless, linux-kernel@vger.kernel.org
On Mon, 2 Mar 2009, Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <greg@kroah.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@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.
>>
>> 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.
kernel.org kernels (and _possibly_ rc's) would have value (I'm glad to see
Ubuntu making this move), but linux-next is not something that should be
pushed out.
>> If they aren't
>> developers, why would any "others" care about our development
>> proceedures?
>
> Right -- in this case above "others" could be developers but could
> also be distribution guys. Essentially I was looking for arguments to
> push and show why linux-next is the next best thing since sliced bread
> for all those nasty deltas.
>
> Which OK -- maybe they can never disappear (?) but hopefully it can at
> least be reduced in size over time.
>
>> Heck, very few developers even read the Documentation files, I'd never
>> expect an "other" to do that :)
>
> 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.
David Lang
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
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
0 siblings, 2 replies; 18+ messages in thread
From: Luis R. Rodriguez @ 2009-03-03 7:57 UTC (permalink / raw)
To: david; +Cc: Greg KH, Jeff Garzik, wireless, linux-kernel@vger.kernel.org
On Mon, Mar 2, 2009 at 11:42 PM, <david@lang.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@kroah.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@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.
>>>
>>> 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
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 7:57 ` Luis R. Rodriguez
@ 2009-03-03 9:16 ` Theodore Tso
2009-03-03 15:19 ` Stefan Richter
1 sibling, 0 replies; 18+ messages in thread
From: Theodore Tso @ 2009-03-03 9:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: david, Greg KH, Jeff Garzik, wireless,
linux-kernel@vger.kernel.org
On Mon, Mar 02, 2009 at 11:57:23PM -0800, Luis R. Rodriguez wrote:
> >> 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:
What kind of distribution kernel are you talking about here? Even for
a community distribution kernel, it typically goes through at least
1-3 months of testing before it is finally released. And an
enterprise distro will snapshot a good six months before release time.
Or are you talking about a bleeding-edge "kernel of the day" that a
distro like Fedora ships?
Also there's a very big difference between getting a bleeding edge
driver which doesn't have much impact on the rest of the kernel, and a
bleeding edge subsystem which may impact other parts of the kernel.
Unfortunately the wireless subsystem is not as immature as other parts
of the kernel, so I've noticed that it's not that rare for a new
driver to depend on new infrastructure in the wireless stack. But in
the long run, hopefully that will go away.
The reason why distro's are hesitant to take bleeding edge code that
hasn't been accepted yet is that it may never be accepted. (Case in
point, the disaster that has been Xen, and the huge amount of pain
this is cost the enterprise distro's, since they've been forced to
dedicated a non-trival amount of engineering resources to backport
hell.)
Or it may be accepted in a different form than what they took in their
snapshot. And/or it might be buggy, causing them to have to deal with
a huge amount of pain trying to fix a particular problem.
For a subsystem where Linus largely trusts the maintainer to send good
pull requests, it may seem that just because something is queued for
the next merge window, it's automatically going to go in during the
next merge window, and so it's fair game to try to pressure
distributions to accept the code before Linus has accepted it.
However, there is always the distinct chance that it won't be accepted
for one reason or another. Or it may be that when it starts getting
testing, it has so many bugs that Linus decides to revert the one or
more patches from mainline, or possibly even the entire merged branch.
In practice, especially for a distribution kernel that gets months and
months of baking, there is typically enough time for a patchset to get
merged into Linus, and for the maintainer to ask the distro to
backport some new functionality which is now in mainline.
- Ted
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 7:57 ` Luis R. Rodriguez
2009-03-03 9:16 ` Theodore Tso
@ 2009-03-03 15:19 ` Stefan Richter
1 sibling, 0 replies; 18+ messages in thread
From: Stefan Richter @ 2009-03-03 15:19 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: david, Greg KH, Jeff Garzik, wireless,
linux-kernel@vger.kernel.org
Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 11:42 PM, <david@lang.hm> wrote:
>> - Show quoted text -
>> On Mon, 2 Mar 2009, Luis R. Rodriguez wrote:
>>> 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.
They want wireless to work and audio to not break.
> 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.
Testers for linux-next are certainly welcome, but these testers need to
understand what the actual topic of linux-next is.
It is an integration-testing tree (for what is anticipated to be part of
Linus' next merge window). Integration testing is for the purpose of
detecting + fixing (or avoiding) problems due to interactions between
subsystems, or between infrastructure code to peripheral code.
Therefore I agree with David that linux-next is somewhat too special for
general consumption.
Before integration testing, we test subsystem developments in a more
targeted fashion in our myriad of subsystem development trees. (These
trees host special branches from which linux-next is created almost
daily in a more or less automated fashion.)
Of course if a distributor wanted to package linux-next, why not. The
nature of -next would call for several of such package releases per week
though.
--
Stefan Richter
-=====-==--= --== ---==
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 7:37 ` Luis R. Rodriguez
2009-03-03 7:42 ` david
@ 2009-03-03 14:53 ` Greg KH
2009-03-03 15:27 ` Stefan Richter
2 siblings, 0 replies; 18+ messages in thread
From: Greg KH @ 2009-03-03 14:53 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Jeff Garzik, wireless, linux-kernel@vger.kernel.org
On Mon, Mar 02, 2009 at 11:37:33PM -0800, Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <greg@kroah.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@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.
> >
> > 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.
Woah!
You started out talking about -stable, and now you are trying to use
that as a reason for a distro to carry -next? Those are on the totally
different end of the spectrum.
It's up to the individual distros if they want to carry portions of
-next (and if you look, they all carry some parts, due to different
reasons).
thanks,
greg k-h
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 7:37 ` Luis R. Rodriguez
2009-03-03 7:42 ` david
2009-03-03 14:53 ` Greg KH
@ 2009-03-03 15:27 ` Stefan Richter
2009-03-03 17:23 ` Luis R. Rodriguez
2 siblings, 1 reply; 18+ messages in thread
From: Stefan Richter @ 2009-03-03 15:27 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Greg KH, Jeff Garzik, wireless, linux-kernel@vger.kernel.org
Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <greg@kroah.com> wrote:
>> 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.
Distros would do their users a bigger favour if they didn't just dump a
random new driver into their kernel package, but if they instead (or in
addition) support the process to get new drivers into the mainline.
It's a favour to their users because maintenance in mainline generally
means better quality. (Less drivers which break suspend/resume etc. pp.).
It's also a favour to themselves because the maintenance of their kernel
as a whole will cost less if it is a stabilized derivative of the
mainline instead of an unstable (and merely potential) predecessor of
the mainline.
--
Stefan Richter
-=====-==--= --== ---==
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 15:27 ` Stefan Richter
@ 2009-03-03 17:23 ` Luis R. Rodriguez
2009-03-03 18:13 ` Stefan Richter
0 siblings, 1 reply; 18+ messages in thread
From: Luis R. Rodriguez @ 2009-03-03 17:23 UTC (permalink / raw)
To: Stefan Richter
Cc: Greg KH, Jeff Garzik, wireless, linux-kernel@vger.kernel.org,
Theodore Tso
On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Luis R. Rodriguez wrote:
>> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <greg@kroah.com> wrote:
>>> 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.
>
> Distros would do their users a bigger favour if they didn't just dump=
a
> random new driver into their kernel package, but if they instead (or =
in
> addition) support the process to get new drivers into the mainline.
>
> It's a favour to their users because maintenance in mainline generall=
y
> means better quality. =C2=A0(Less drivers which break suspend/resume =
etc. pp.).
>
> It's also a favour to themselves because the maintenance of their ker=
nel
> as a whole will cost less if it is a stabilized derivative of the
> mainline instead of an unstable (and merely potential) predecessor of
> the mainline.
I don't think I was very clear in what I meant about "carrying
linux-next kernel packages as an option". What I meant was carrying it
just as an option for those users who want to test bleeding edge
without compiling their own linux-next, _not_ to merge linux-next
things into their own default kernel release and shove it down users
throats.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 17:23 ` Luis R. Rodriguez
@ 2009-03-03 18:13 ` Stefan Richter
2009-03-03 18:43 ` Luis R. Rodriguez
0 siblings, 1 reply; 18+ messages in thread
From: Stefan Richter @ 2009-03-03 18:13 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Greg KH, Jeff Garzik, wireless, linux-kernel@vger.kernel.org,
Theodore Tso
Luis R. Rodriguez wrote:
> On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>> Luis R. Rodriguez wrote:
>>> 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.
>> Distros would do their users a bigger favour if [...]
>
> I don't think I was very clear in what I meant about "carrying
> linux-next kernel packages as an option". What I meant was carrying it
> just as an option for those users who want to test bleeding edge
> without compiling their own linux-next, _not_ to merge linux-next
> things into their own default kernel release and shove it down users
> throats.
Sorry, I meant "bigger favour" relative to carrying an own delta of
considerable size.
Packaging linux-next would be fine if the workload isn't a problem for
the packager. As pointed out elsewhere, there are caveats with
linux-next (e.g. a functionality which was in it yesterday could be gone
today because of a merge issue), but that's the nature of bleeding edge
of course.
--
Stefan Richter
-=====-==--= --== ---==
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 18:13 ` Stefan Richter
@ 2009-03-03 18:43 ` Luis R. Rodriguez
2009-03-03 22:55 ` david
0 siblings, 1 reply; 18+ messages in thread
From: Luis R. Rodriguez @ 2009-03-03 18:43 UTC (permalink / raw)
To: Stefan Richter
Cc: Greg KH, Jeff Garzik, wireless, linux-kernel@vger.kernel.org,
Theodore Tso
On Tue, Mar 3, 2009 at 10:13 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Luis R. Rodriguez wrote:
>> On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>>> Luis R. Rodriguez wrote:
>>>> OK small silly example is convincing distributions it may be a goo=
d
>>>> idea to carry linux-next kernel packages as options to users to
>>>> hopefully down the road reduce the delta between what they carry a=
nd
>>>> what is actually upstream.
>>> Distros would do their users a bigger favour if [...]
>>
>> I don't think I was very clear in what I meant about "carrying
>> linux-next kernel packages as an option". What I meant was carrying =
it
>> just as an option for those users who want to test bleeding edge
>> without compiling their own linux-next, _not_ to merge linux-next
>> things into their own default kernel release and shove it down users
>> throats.
>
> Sorry, I meant "bigger favour" relative to carrying an own delta of
> considerable size.
>
> Packaging linux-next would be fine if the workload isn't a problem fo=
r
> the packager. =C2=A0As pointed out elsewhere, there are caveats with
> linux-next (e.g. a functionality which was in it yesterday could be g=
one
> today because of a merge issue), but that's the nature of bleeding ed=
ge
> of course.
Sure, understood. That's all I meant really.
My argument here I guess is that the reasons used to support the
"equivalent fix" policy for patches upstream makes it apparent why
linux-next is so important and my hope would be to get it more
exposure by having distributions let users test it (as an option to go
with bleeding edge) and this in turn help stabilize code in our next
release.
But I certainly don't expect every distribution to carry such a
package, nor would I expect them to want to deal with it. Just wanted
to build a good case for distributions to consider it.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Elaboration on "Equivalent fix must already exist in Linus' tree"
2009-03-03 18:43 ` Luis R. Rodriguez
@ 2009-03-03 22:55 ` david
0 siblings, 0 replies; 18+ messages in thread
From: david @ 2009-03-03 22:55 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Stefan Richter, Greg KH, Jeff Garzik, wireless,
linux-kernel@vger.kernel.org, Theodore Tso
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2010 bytes --]
On Tue, 3 Mar 2009, Luis R. Rodriguez wrote:
> On Tue, Mar 3, 2009 at 10:13 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>> Luis R. Rodriguez wrote:
>>> On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
>>> <stefanr@s5r6.in-berlin.de> wrote:
>>>> Luis R. Rodriguez wrote:
>>>>> 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.
>>>> Distros would do their users a bigger favour if [...]
>>>
>>> I don't think I was very clear in what I meant about "carrying
>>> linux-next kernel packages as an option". What I meant was carrying it
>>> just as an option for those users who want to test bleeding edge
>>> without compiling their own linux-next, _not_ to merge linux-next
>>> things into their own default kernel release and shove it down users
>>> throats.
>>
>> Sorry, I meant "bigger favour" relative to carrying an own delta of
>> considerable size.
>>
>> Packaging linux-next would be fine if the workload isn't a problem for
>> the packager. As pointed out elsewhere, there are caveats with
>> linux-next (e.g. a functionality which was in it yesterday could be gone
>> today because of a merge issue), but that's the nature of bleeding edge
>> of course.
>
> Sure, understood. That's all I meant really.
>
> My argument here I guess is that the reasons used to support the
> "equivalent fix" policy for patches upstream makes it apparent why
> linux-next is so important and my hope would be to get it more
> exposure by having distributions let users test it (as an option to go
> with bleeding edge) and this in turn help stabilize code in our next
> release.
what does "equivalent fix" in the linus tree have to do with -next?
patches don't go always go through -next to get to linus, things that are
in -next don't nessasarily _ever_ get to linus.
you are mixing issues here.
David Lang
^ permalink raw reply [flat|nested] 18+ messages in thread