> Exactly. On the other hand, keep an absolute feature freze, and don't start
> 2.3 until a real 2.2 is out the door. Changing from a 2.1.x strand to a
> 2.2.0-preX strand would do that.
>
> -=- James Mastros
>
> PS -- I don't think that 2.3 should last nearly as long as 2.1 did -- one
> major improvement, and that's it. IMHO, we could have had a 2.2 by now if
> sombody hadn't jumped the gun on the SMP IRQ changes <G>. That would have
> two major re-designs: the dcache and smart-config. Now we are working on
> getting the bugs out of the third.
Don't forget copy_*_user(), the feature that pretty much kicked off
2.1.X, or the gradual changeover to spinlocks, TCP/IP enhancements
(which were backported to 2.0 in the "SPS" series by Dave Miller that
became 2.0.30) or the modularization of the sound driver... that's 7
major changes to the kernel, plus the traditional ploethera of new
drivers and filesystems and all. And even w/o the IO-APIC stuff,
dcache is still not completely hammered out (umsdos etc need to catch
up, and has anyone ever found what caused those random dcache
corruptions?), spinlocks are making progress, and TCP and sound are a
little too ragged for a stable release at the moment. So I don't
think 2.2.0 would _quite_ be out the door just yet...
But I think you're right, the case is _very_ strong for shortening the
development cycle in the future. But that's Linus's call, and I'm not
one to second-guess the wisdom of our fearless leader ;-)
Opinions, nothing more,
Adam
-- Things look so bad everywhere Adam D. Bradley artdodge@cs.bu.edu In this whole world what is fair Boston University Computer Science We walk blind and we try to see Ph.D. student and Linux hacker Falling behind in what could be ----> Bring me a Higher Love ----> <><- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu