On Thursday 11 November 2010 09:51:34 Jonathan Corbet wrote: > Hi, Rob, > > > Look: Linux has to deal with binary only modules, which the developers > > hate. To compensate for this, they go out of their way to avoid having a > > stable internal API (which could argualy be used as a copyright barrier > > and thus prevent the modules from being derived works of the Linux kernel > > to which GPLv2 must apply). To avoid this, they break internal > > compatability essentially every release. They go out of their way _not_ > > to make forward- porting modules easy (otherwise they'd have a checklist > > each release saying do this this and this, and you'll be up to date). > > Suffice to say I disagree with this characterization; one should not > confuse a lack of sympathy for maintainers of out-of-tree modules with a > deliberate attempt to make life hard.
There's a fine line between wilfully obtuse and actively obstructive. The "merge your damn code already" camp has excellent engineering motivations, and they certainly have plausible deniability. Having seen Greg speak on the topic more than once (his OLS "binary only modules are definitely illegal" talk comes to mind), I find it easy to ascribe deliberation to him, but I'm not a mind reader. > There are other reasons for the > internal API policy, but I doubt anybody would benefit from an extended > discussion of them here. I readily admit I'm over-simplifying the actions of ~300 guys over the past decade, and they don't all agree. Linus's policy seems merely to be "Shut up and show me the code", as always, and nobody else speaks authoritatively for the kernel. > One little point of fact, though: > > Some people weren't happy with that, and decided to set up an > > intermediate staging area to help distros coordinate their long term > > support efforts. Adrian Bunk backported bugfixes to 2.6.16 for several > > years: > > > > http://kerneltrap.org/node/6930 > > http://kerneltrap.org/node/7164 > > http://lwn.net/Articles/266707/ > > > > And when that became hopelessly out of date he moved to 2.6.27: > > > > http://lkml.org/lkml/2008/10/12/2 > > Adrian has not had a patch merged for over a year, and has never gone near > 2.6.27. That kernel is maintained by Greg Kroah-Hartman; it looks like > Willy Tarreau may pick it up at some future point. I vaguely recall a message wandering by from Adrian circa 2008 about him giving up on 2.6.16 and picking up a new kernel. Doesn't mean it happened. For one thing, Greg's -stable series was well underway by then, and he picked up my suggestion of "one last -stable when the new kernel comes out so there's no gap between versions bugfix-wise, and anybody stuck on an old kernel can look at all the bugfix-only patches for the new kernels since them and try to backport fixes without any obvious gaps between the last 2.6.n.x and the start of 2.6.n+1 where bugfixes went in but weren't broken out". It's not perfect, but -stable took a lot of the wind out of the LTS kernel sails. I believe he moved on to maintaining the regression list instead (same motivation, different solution). Between the busybox FAQ entry I linked to earlier, and the time based releases video, I hope I've documented why attempting to maintain "old stable" versions does not help an open source project actually do development. For a project like the kernel that's got engineering effort coming out its years, yay. They have spare bandwidth. For a project like uClibc or busybox where we've had major architectural todo items going begging for MORE THAN FIVE YEARS now? (Yes seriously: uClibc still has pthreads.old, pthreads.new, _and_ NPTL hanging around unfinished. Busybox has three shell implementations and none of them is a decent bash replacement, we've settled on hush as the way forward but it needs six months of full-time work before we can delete the crufty old maze of ash code, plus the testsuite is in three different formats and bits of it are scattered all over the tree...) Pulling existing developers off of that to babysit a "dead tree" version of the code is not the best use of their time. If that's what a new developer wants to do, they're welcome to bell that cat. > jon Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox