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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
