Hi,
I accidentally deleted all the messages in my debian-user folder
<sigh>. However, I do remember enough of your original post to
(hopefully) enlighten you. I have also done the nasty cross-post
thing to -devel because I conclude with a thought on how to get the
package pool living up to its potential.
There is no way to show anyone what the next Debian will look like
until it is released .
^^^
You can see which packages are being worked on for inclusion in the
next release (those in unstable), but until the release is made there
is no way to tell if a package will get enough of its known bugs fixed
to be included. Even a package being in testing when a freeze comes
along does not provide enough information with which to make that
determination.
Debian unstable, testing, and stable archives are not development,
pre-release, and released archives... until a freeze comes along.
Maybe this will help...
Flow of new software into Debian's archives:
1 2 3
--- --- ---
N) upstream+ ---> unstable ---> testing stable
F) upstream+ ---> unstable testing stable
R) upstream+ ---> unstable testing ---> stable
1, 2, and 3 represent the movement of packages; N, F, and R indicate
Debian's "normal", "in a freeze", and "release" modes of operation;
upstream+ represents the original source plus modifications made by a
Debian developer; unstable, testing and stable are Debian archives.
1 can happen at any time and is controlled by the autobuilder; 2 can
only happen between freezes and is controlled by the bug tracking
system (BTS); 3 is a manually triggered operation whose timing is
determined with input from the BTS and developers.
To put it into perspective... once (only one or two releases ago)
there was just unstable and stable, testing only existed during a
freeze. Release cycles were too long and developers didn't like
having to put development of new software on hold when a freeze came
along, so they decided to do away with separate archives and move to a
"package pool" system -- all packages actually exist in a common pool
and specific versions are flagged as being included in one or more
virtual archives. The idea being that developers could continue to
develop at their own pace and relatively stable packages would
automatically accumulate in testing, at some point testing would look
good enough to freeze and then release as the current stable.
Speculation/opinion:
Why is testing in such bad shape...
It seems to be the case that developers are moving packages through
unstable too fast for testing to reach a point where it looks good
enough to freeze and polish into a release.
What could be done to fix the situation...
Create a permanent "frozen" archive, fed from a consistent set of
packages in testing which have been flagged as release candidates.
By "set of packages" I mean all the packages which make up, for
example, Gnome or Gnome2 or KDE2 or KDE3, etc. If only one version of
a set is allowed to be a release candidate at any point during a
release cycle, and only packages which have achieved stability are
allowed to move into the frozen archive... "testing+frozen" will
quickly become what users want "testing" to be (a peek at the next
Debian), and the release manager only needs to look at the quantity of
packages in frozen to determine if it is time (are all or enough of
the release candidates here?).
Useful Debian systems with the existence of a "frozen" archive...
(where your sources.list lines point to)
unstable Developers developing and users who don't mind
bleeding from time to time.
testing/unstable Users who don't mind getting hurt as long as
first aid is likely to be available.
testing Crazy people, this could contain (for example)
Gnome, Gnome2, KDE2 and KDE3, all at the same
time! Basically a holding area for packages
transitioning from development to pre-release.
frozen/testing Developers polishing and users wanting a peek
at the next release.
frozen Anyone interested in how far along the next
release has progressed. Stable quality, but
not a complete distribution.
stable most users
Flow of new software within a Debian with a "frozen" archive:
| --- development ---|--- pre-release ---|----- released -----|
| phase | phase | |
unstable ------> testing -----> frozen ---> stable, archived
1 2 3
0 - (not shown) flow into unstable, controlled by the autobuilder
1 - controlled by the BTS
2 - BTS (tighter restrictions than 1) and developer input via a
release candidate flag
3 - BTS and release manager (who could be a program which
automatically makes a release when all required, important,
and standard packages have made it into frozen and are bug free)
- Bruce
