The key thing I look at is total cycle time, from any particular point
in the cycle, to when that same point comes around again.
In 2.4 and before, the cycle time was a long time, I hear tell.
Perhaps, at some points, things were sufficiently chaotic that it
was difficult to discern any particular cycle time (FFT of releases
resembled pink noise ;?).
In 2.6.x since June 2004, the cycle time has been two months. Cool.
My employer (SGI) has to push new features through the main Linux
kernel, and then through the Linux distributors we work with, such as
SuSE and Red Hat, before they reach our customers. And we tend to live
on the leading edge, so depend on these features.
The longer the new feature cycle time in Linux, then the longer on the
average (depending on just how we line up) it takes us to get a feature
to our customers.
I really like the two month cycle we have now. It's fast.
If your 2.6.<odd>, 2.6.<even> proposal extended that cycle time to four
months (two months <odd>, two months <even>), that would hurt. Not the
end of Planet Earth, but still an owie.
The times you give, of a month or two for the <odd>, and a week or two
for the <even>, if taken literally, add up to roughly the same two
months, give or take a few weeks. This is good.
But I've long since learned to take initial time estimates from
engineers (and from my wife, when we're getting ready to go out) with
a few grains of salt.
How serious are you about these time estimates?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
