Ken Teague wrote:
> Barclay, Daniel wrote:
>> 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.)
>
> How much of what?
How much change (new features, re-implementations, new packages); how much
work.
> It sounds like you answered your own question in the tail end of the
> paragraph.
How? (How does it sound like that?) People rarely address how the length
of Debian's release cycle is affected by how much change Debian tries to
incorporate into each release.
>> 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.
>
> Debian is a package-based distribution. Mentioning the changes in N
> thousand packages is not only very time consuming, but it doesn't apply
> to each individual user. As such, I don't think the majority of us
> would want to weed through a long list of changes to find out what has
> changed.
Why are you about mentioning individual changes? I didn't say or mean to
imply anything like that.
If Debian set a shorter target release interval, each individual package
maintainer would implement (and test and debug) a smaller set of features
and changes (for that package) for each (more frequent) release. I don't
think there's any need for listing all the changes. What were you thinking
about? (Why would listing be or have been needed?)
> Also, with the way Debian is released (when it's ready)
Your saying that seems to indicate that you're still missing my point (that
people seem unaware of the quantity aspect when mentioning the quality
aspect).
Debian's long release cycle is not a result of _just_ Debian's quality.
It's _also_ a result the "chunk size," the quantity of change collected
together before freezing, testing, debugging, re-testing, etc. until it's
up to Debian quality standards for releasing.
Consider making two changes. You could implement, test, debug, and re-test
both before making a release containing both. Alternatively, you could
implement one, then test/debug/re-test it fix it, and then make a release
containing just that first change before starting to implement the second
change.
Doing it the second way does _not_ have to compromise any quality standards.
(Why do you (seemingly) think it does?)
Doing it the second way would mean that each release is not as old (as they
are currently) when it is released and does not get as old (as they do
currently) before the next release is released. (E.g., the first change
doesn't have wait for the release containing the second change.)
Doing it the second way does likely take slightly longer (since part of
the quality-checking process and the release process itself happen multiple
times).
Except when changes can't be divided into two chunks like that, making two
smaller releases rather than one big one would very likely let Debian releases
be more current, with no loss of quality. The cost would be some decrease
in average development speed of Debian.
The question, of course, is whether shortening Debian's release cycle length
by a factor of, say, 2 or 1.5 (from the current length), would cost only a
very small relative amount of time and effort, small enough to be worth
doing so that Debian stable releases wouldn't initial be or become so
old, or would be a significant drain.
That's the topic I'm having trouble getting to, because people think I'm
saying Debian should reduce its quality and because many people can't seem
to see that the release cycle length is not determined _only_ by Debian's
quality standards.
> , there's a time
> when the testing tree is put into a "freeze". This means that the
> version of the package itself doesn't change and only bug fixes are
> implemented at this point. At this point, you can check for yourself
> which changes are in the packages you plan to use.
I don't follow; when does checking for changes have to do with the
discussion (about the "chunk size" of changes and releases)?
>
>> Obviously, not everything is simply divisible like that--e.g., a big change
>> that takes many months to design, implement, and test.
>
> Changes to the way Debian functions are mentioned in the mailing lists
> and is updated in its documentation. ...
True, but, again, how does that relate?
>> 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 [does] 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)?
>
> Debian doesn't have a set release cycle, as you've noticed. It's long
> because they want to produce a distribution that's very stable and
> contains little or no bugs.
No. Again, it's long because of that AND because of the chunk size.
How do you (and others that replied to my message) keep missing that?
Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]