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.
[1] http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
[2] git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
Luis
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 [email protected] 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
Jeff
On Mon, Mar 02, 2009 at 09:43:26PM -0800, 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.
Simple is better, do you really want a longer version of that same file?
Is there something confusing in it?
And as always, a simple:
Cc: stable <[email protected]>
in the patch itself is the easiest way to get it automatically included
in the next -stable releases after it hits Linus's tree.
What more do people want? Personal invitations?
Is it time to break out the caligraphy pens and wax seals?
thanks,
greg k-h
On Mon, Mar 2, 2009 at 9:57 PM, Jeff Garzik <[email protected]> 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 [email protected] 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
Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 9:57 PM, Jeff Garzik <[email protected]> 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 [email protected] 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
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 <[email protected]> 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 [email protected] 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? If they aren't
developers, why would any "others" care about our development
proceedures?
Heck, very few developers even read the Documentation files, I'd never
expect an "other" to do that :)
thanks,
greg k-h
On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <[email protected]> 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 <[email protected]> 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 [email protected] 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.
> 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.
Luis
On Mon, 2 Mar 2009, Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <[email protected]> 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 <[email protected]> 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 [email protected] 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
On Mon, Mar 2, 2009 at 11:42 PM, <[email protected]> wrote:
> - Show quoted text -
> On Mon, 2 Mar 2009, Luis R. Rodriguez wrote:
>
>> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <[email protected]> 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 <[email protected]> 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 [email protected] 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
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
On Mon, Mar 02, 2009 at 10:27:21PM -0800, Greg KH wrote:
> And as always, a simple:
> Cc: stable <[email protected]>
> in the patch itself is the easiest way to get it automatically included
> in the next -stable releases after it hits Linus's tree.
>
> What more do people want? Personal invitations?
>
> Is it time to break out the caligraphy pens and wax seals?
Why do you torment me with humor like this?
YES! Of course I want to see how Greg K-H's caligraphy looks.
Just picturing you hunched-over a box of stationary will keep me
humored for days... :-)
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
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 <[email protected]> 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 <[email protected]> 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 [email protected] 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
Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 11:42 PM, <[email protected]> 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/
Luis R. Rodriguez wrote:
> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <[email protected]> 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/
On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
<[email protected]> wrote:
> Luis R. Rodriguez wrote:
>> On Mon, Mar 2, 2009 at 11:26 PM, Greg KH <[email protected]> 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.
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
Luis R. Rodriguez wrote:
> On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
> <[email protected]> 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/
On Tue, Mar 3, 2009 at 10:13 AM, Stefan Richter
<[email protected]> wrote:
> Luis R. Rodriguez wrote:
>> On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
>> <[email protected]> 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.
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
On Tue, 3 Mar 2009, Luis R. Rodriguez wrote:
> On Tue, Mar 3, 2009 at 10:13 AM, Stefan Richter
> <[email protected]> wrote:
>> Luis R. Rodriguez wrote:
>>> On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
>>> <[email protected]> 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