Re: Bits from the RM
On Aug 20, Theodore Ts'o (tytso@mit.edu) wrote:
> The real problem is that stable has a reputation of taking years and
> years before we manage to do a release, so people are always desperate
> to shove every last bit of functionality and new upstream release into
> it. What folks don't realize is that makes the problem worse, not
> better, by stretching out the release schedule.
Bravo, well put.
> Better to have a hard freeze schedule, and then try to turn out new
> stable releases every 6-9 months. Then folks won't be so desperate to
> shove new things in and screw up the release. The problem, though, is
> the first such attempt take release schedules seriously and
> agressively (a) a really hardass RM, and (b) a certain amount of faith
> by the developers that we really can get our act together about short,
> regular, predictable releases.
I'm completely in favor of (a) in order to improve the release frequency. I
suppose that might come back to bite me someday, but so be it :-)
As for (b): I firmly believe the critical element is some kind of plan with
either specific times or milestones that we can work toward. Since ajt just
sent out such a plan, I think we can do it.
Some seem to think that we could get KDE3.2 into the next release and not
stretch out the release schedule. That implies that it would not be very well
tested and less stable than KDE 3.1. In my business, what you put at risk by
releasing unstable software is large amounts of money, your job, or both. It
is ludicrous to think that people who have to deploy Debian in such an
environment would prefer that the new "stable" release contain the newest,
barely tested, less stable versions of major packages rather than slightly
older, better tested, more stable versions.
--
Neil Roeth
Reply to: