On Wednesday 03 July 2002 11:34 am, Dave Jones wrote:
> On Mon, Jul 01, 2002 at 02:25:16PM -0400, Bill Davidsen wrote:
> > I suggested that 2.5 be opened when 2.4 came out, so I like the idea of
> > 2.7 starting when 2.6 is released. I think developers will maintain the
> > 2.6 work out of pride and desire to have a platform for the "next big
> > thing." And their code can always be placed on hold for 2.7 until they
> > clarify their thinking on 2.6, if that's really needed.
>
> Unfortunatly, there's the possibility of people thinking
> "I'll fix it properly in 2.7, and backport", during which time,
> 2.6 doesn't get fixed any faster. People diving into 2.7 development
> and leaving 2.6 to those that actually care about stabilising it was
> Linus' concern if I understood correctly at the summit.
And leaving stabilization to the people who care about stabilization would be
a bad thing why? 2.4's first ten releases are a marvelous counter-example to
the "stonewall new development to speed up bugfixing" theory of software
development. The musical rotating feature freeze/thaw/slush/slurpee halfway
through development cycles haven't been that effective either.
Linus ain't so good at maintenance, and he has said as much on this list.
Linus's kernel sets the direction for Linux evolution, but he couldn't get
the 2.4.0 VM stabilized and Alan Cox did. (Better than mainline, anyway.)
If Linus had handed over the stable series to Alan right after 2.4.1, taken a
month long vacation, and then opened a new branch that was a bit selective at
first about what it took and from who, does anybody think 2.4 would have
taken any longer to properly stabilize than it wound up doing? (Did Jens's
bio patches really need to wait on the VM stabilization work? Did Jens help
stabilize the 2.4 VM?)
We live in a world of multiple Linux kernel trees already, each with a
different maintainer who is good at different things. Linus is a brilliant
architect who is great at plucking the best ideas from the cream layer of the
churning mass of Sturgeon's Law flung at him on a daily basis. When
presented with four ways to do something, he'll spot the hidden fifth better
way like nobody else can. But saying no in such a way as to promote
stability is a different skill, and last time Linus went into big time
"saying no" mode he wound up dropping VM stabilization patches from the then
VM maintainer. And the feature freezes haven't historically been remarkably
effective at producing a stable kernel soon after either.
A "stabilization fork" off of the development series could be done, as an
experiment, during the next "feature slush". A maintainer who specializes in
stabilizing code (You, Alan, and Marcelo are all doing a decent job at this
now: it's not a common skill but not as rare as being a brilliant architect
like Linus) can fork a "fixes only" tree that may or may not become 2.6, and
see how it goes.
It it works, great, if it doesn't work, fine. You already maintain a fork
off of Linus's tree, and Alan maintains one off of Marcelo's tree. Red Hat
and SuSE maintain their own forks as well. The existence of such a fork,
with a compentent maintainer and its own user base, is not inherently
disruptive to the rest of the world. Feeding patches from one tree into
another and dropping the rest until they're merged is what you and Alan do
normally anyway, so the down side of it NOT working (giving up after a few
months and going "shucks, people just won't listen to anyone but Linus")
isn't exactly catastrophic. As long as the maintainer is competent at
merging to clean up the fork afterwards, and if they're not they can't
effectively maintain their own tree in the first place anyway.
An explicit stabilization-only fork could even be a tool to help Linus's fork
stabilize (if that is or becomes the goal), by tracking down bugs and
performance tuning in a less turbulent environment while trying hard to
introduce as few new problems as possible, and that being the ONLY goal of
the fork. Lots of bugs have been tracked down in -dj or -ac and the fix then
ported to the appropriate mainline later.
If the stabilization fork DOES become 2.6, then 2.6 can START with a new
maintainer, like Marcelo for 2.4 and Alan for 2.2. Stable branch maintainers
aren't normally expected to make major new architectural decisions anyway,
that's what development kernels are for. :)
And if nothing else, it reduces the likelihood of development being stuck in
a nebulous "no new features, well, okay, one more but that's it" mode for
most of a year.
Yes, in theory 2.5 should BECOME a stabilization fork, under Linus, during
the feature freeze. It might even happen this time. But how would hedging
the bet hurt?
> Dave
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:11 EST