s. keeling wrote:
> Koh Choon Lin <email@example.com>:
>> Anyone has an idea what is the release cycle for Debian? I
>> understand six months is the standard for Ubuntu.
> Why? What's wrong with Etch and Lenny? They're both well usable now,
> yes? Are you looking for Lenny features in a "stable" release?
> Debian *takes its time and does it right* (generally speaking).
> That's what Debian's always been about. That's why *buntu exists.
>> Also, when can binary for 4.0r6 be expected to be released?
> When it's right. This is *basic* Debian philosophy. If this doesn't
> work for you, you're either doing it wrong or you're in the wrong
Why do so many defenses of Debian's release cycle length seem to ignore or
skirt the issue of _how_ _much_ is planned to be in each release? (Saying
"when it's right" still depends on what "it" is--which set of features/
changes are involved.)
If there's only one feature or thing to do, it's easy to say whether
it's done (right) or not.
However, when you're releasing N thousand changes every 18 months or so,
it's arguable that maybe you should be releasing N/2 thousand changes every
9 or 10 months.
Obviously, not everything is simply divisible like that--e.g., a big change
that takes many months to design, implement, and test.
Is Debian's stable release cycle relative long because Debian releases
typically involve big changes that set the minimum time between releases,
or is it because Debian not really attempt to design and make smaller, more
frequent increments in order to keep Debian stable releases from getting so
(relatively) old (while maintaining quality standards)?
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]