Re: Release Cycle
Barclay, Daniel wrote:
>
> Ken Teague wrote:
> How much change (new features, re-implementations, new packages); how much
> work.
This is because Debian is a packaged-based distribution and there are
litterally thousands of packages that change with bug fixes, new
features and so on. This also answers the question on new and obsolete
packages. Debian package maintainers come and go, or no longer wish to
support a certain package which then becomes orphaned and dropped from
the list. More info on packages can be seen here:
http://www.debian.org/devel/wnpp/
> 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.
The changes are mostly incorporated into the various packages and the
Linux kernel. I don't think most Debian users are concerned with the
length between release cycles. They're concerned with stability first,
features second. Those who are the opposite have moved to using Ubuntu.
I may be wrong, but that's the way I've always seen it.
> Why are you about mentioning individual changes? I didn't say or mean to
> imply anything like that.
Because, again, Debian is a package-based distribution and the majority
of the changes are within those individual packages and the Linux kernel
that is distributed with the release. There are some changes to Debian
itself, but normally very little. For example, when 4.0 was released,
they added a graphical interface to the Debian Installer. If this
doesn't answer your question, please provide me with some examples of
what you're looking for.
> 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?)
It seems that I may be having troubles understanding what you're
thinking about. Are you asking when does the Debian release team decide
when to put a freeze on testing?... and when to set a release date for
what's been in freeze?
> 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.
There are four parts to this; changes in packages, changes in
"Debianism" (aspects specific to Debian), new packages (and what they
offer), and obsolete and/or orphaned packages. You're right -- the
duration between releases tend to incorporate a *lot* of changes.
> 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.
Debian works in both ways, depending on how important the release team
feels about the feature(s). I think this also is what they base a
release date on, after it has been in freeze.
> Doing it the second way does _not_ have to compromise any quality standards.
> (Why do you (seemingly) think it does?)
Perhaps I wasn't understanding you correctly the first time around.
Perhaps I'm still not understanding you this time around. Nevertheless,
I'm only trying to help you out. If you don't want my help, I'll kindly
step to the side and see if anyone else wants to step up to this plate.
> 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.
I think I understand, and this would be nice. I can't speak for every
Debian developer out there, but perhaps it's an issue with the time they
have to work on their projects and packages. Debian is a non-profit
organization, not a commercial company that has time and resources
dedicated to providing timely releases.
> 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.
I can't put an exact number on it, but I think there are more than a
thousand Debian developers from various parts of the world, each of whom
have a life outside of Debian development. Without payment, I don't
think such a feat can be accomplished. How does Ubuntu do it? I think
kit's because Debian developers are footing most of the work for them.
> I don't follow; when does checking for changes have to do with the
> discussion (about the "chunk size" of changes and releases)?
>
> True, but, again, how does that relate?
It was a matter of me trying to understand what you're trying to get at.
I may still be incorrect in interpreting what you're trying to
accomplish, but it sounds like you're coming at this from a commercial
perspective where a *company* has time and resources to achieve the
goals you're speaking of. Again, Debian is a non-profit organization.
> 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?
Again, I could be wrong, but I think you just answered your own question
again. :-) The longer the duration between releases produces (what you
call) a larger "chunk size". As such, it takes longer for the features
within the "chunk size" to be tested, debugged, and fixed.
Personally, I'm not used to seeing anyone on this mailing list coming at
me like a product manager trying to push a product out of the door, so
it threw me off. Sorry for the misunderstanding.
- Ken
Reply to: