Re: Elaboration on "Equivalent fix must already exist in Linus' tree"

["Luis R. Rodriguez" <mcgrof@gmail.com>]

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.

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