On Tue, 3 Mar 2009, Luis R. Rodriguez wrote:
On Tue, Mar 3, 2009 at 10:13 AM, Stefan Richter
<stefanr@xxxxxxxxxxxxxxxxx> wrote:
Luis R. Rodriguez wrote:
On Tue, Mar 3, 2009 at 7:27 AM, Stefan Richter
<stefanr@xxxxxxxxxxxxxxxxx> 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
