> The (real or imagined) need for a "stable" base very much indicates a
> failure of the development process to me.
Most users don't want to upgrade their software daily -- "the software
is here for me, not the other way around". Users will happily wait
years and long as the old photoshop (gimp, whatever) does what they
But security updates are different: through no fault of the user,
he has to update because he is screwed if he doesn't update soon.
If software A needs to be updated and requires updates to software
B, C, and D, then pretty soon the menus in a program have changed
and two others are broken until the authors update them to work with
the newer libraries.
So clearly a stable base is needed -- for the kernel as well as other
parts of the software stack. Distributions fill this role reasonably
> A fear of regressions is of course real, but better addressed by
> test-driven development
Lovely in theory, but for the kernel with bugs that often depend on
insanely complex interactions between multiple programs and/or
machines, I don't think anyone has a workable inkling about how to
even begin doing that.
> code review, better quality assurance, and other such mechanisms.
Infinite, highly skilled man power is a pipe dream. (There wouldn't
be any need for security updates if it wasn't.)