No, it isn't.
> I fail to see the necessity of rushing into a freeze,
The freeze date freeze was set and publicized more than 6 months ago. Define
"rushing".
> especially
> when it seems obvious that people are trying to merge code which hasn't
> been adequately tested.
There will always be code that's not ready before the freeze, and that won't
make it in. If this wasn't the case, there wouldn't be a need for a cutoff
date, would there? "Oh, development is over, there are no more interesting
new patches anywhere, we can all go home now." Doesn't happen.
Thawing the freeze won't help. As time approaches zero, effort approaches
infinity. (Remember college? How many papers did you hand in BEFORE they
were due?)
Meaningful deadlines have a nice motivating effect. Endless extensions are
just sloppy.
> I think Hans Reiser and others have brought up
> valid points that the freeze is happening too soon. I tend to agree,
> especially looking back at the timetable surrounding 2.1.X development.
2.1.X had a timetable?
(I mean, retroactively it had a time table, sure. But are you implying there
was some sort of planned schedule anybody paid attention to at the time? I
must have missed it. There was a lot of "we really mean it this time,
honestly", and "just this once, but don't do it again". But I don't remember
anybody actually paying attention after the first couple of times...)
> Since I'm not a contributor, I know my opinion doesn't count for much.
> Still, as a user I think it is important not to write of new features just
> because they didn't make the "arbitrary" freeze date. Again, I really
> don't see what the rush is all about.
Who says anything about writing off features? 3.0 isn't the end of the world.
The kernel team is trying to get it out now so people don't have to wait
another year or more to use the new features that have ALREADY gotten in.
With a snappy enough cycle time, it's possible to get this stable series into
the hands of users, open the next development branch, and have that one
stabilised and released before a traditional "two years plus" development
cycle like 2.3 or 2.1 would get to its FIRST dot-0 release (with the
obligatory brown paper bag bugs, since it's been so long since anybody
actually used the thing in production..).
Slowing down the development cycle does not speed the introduction of
features. Really.
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/