[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Archive Restructuring - Package Pool


	This is all very well, but I would like to clarify why this is
 important; I think the benefits and procedures should be stated up
 fron. Please consider adding this to the porosal as an preface or
 motivation section; after all this is mostly your document, with
 additions from me (somehow, this was lost in the editing).

	Secondly, Could this be made available on a web page somewhere?

It has become apparent that there are some ways we could improve our
release techniques:

        1) Better control over the release cycle
        2) Better support for users' different stability requirements
        3) Better synchronisation amongst different architectures
        4) Better integration of non-us into the distribution

1) We need to have better control over our release cycle, and in
   particular the ability to ensure that we can easily release the
   work that we have already completed when we choose.

To address this, we need to do three things: ensure that our goals for
each release are reasonable (unaddressed by this document), limit the
extent of any bottlenecks in the release cycle, and ensure that if any
goals prove intractable, that we have a position to fallback to that
does not jeopardise other goals.

The most significant bottleneck in the hamm release has been felt
between the freeze and the (still upcoming) release itself. There were
three significant factors in that delay that are addressed here:

      * the final testing of the distribution by the testing-group
      * the number of release-critical bugs in packages to be released
      * the creation of boot disks and official CDs

The first problem can be eased by letting the testing-group test
packages throughout the release cycle, rather than only at its

The second problem can be addressed by requiring that, in general,
packages will not be considered for release while they have any
unresolved release-critical bugs, and, where that is not possible, by
ensuring that any bugs that do end up delaying release (rather than
simply the release of a particular package) are highlighted throughout
the release cycle so they may be fixed at the earliest possible stage.

The third problem can be addressed by requiring that no packages which
require changes to bootdisks or official CDs will be considered for
release until those changes have been made. This extends more
generally to ensuring that packages will not be considered for
release, until their dependencies may be satisfied by releasable

We can satisfy all these considerations by creating a new area
between "stable" and "unstable"; where packages that are believed
(with some degree of evidence) to be ready for release may be placed
for further testing. This will form a set of packages in a "prelease"
form, that are in the final stages of being ready for release.

Falling back to an old versions of a package is a useful option when a
release-critical bug that does not have a ready fix is found. As such,
it would be convenient to retain a number of versions of a package,
beyond the current stable, prerelease and unstable versions of that

2) We should structure our releases to support each of the three major 
   categories of users:

           a) those who require a robust, bug-free system and do not
              wish to be bothered by constant change, who want
              security updates made available, but would rather keep
              other changes restricted to a few large upgrades each

           b) those who do not wish to be bothered by anything more
              than the occassional, not too severe bug, but want to
              stay up to date with the latest packages.

           c) those who want the absolutely latest version of
              everything, and are willing to work around possibly
              severe bugs.

Debian already serves the first group of people reasonably well with
its "stable" distribution, but currently attempts to satisfy both the
second and third group with its "unstable" distribution. However as
there is no testing done on packages in the "unstable" distribution
save that performed by the maintainer, severe bugs can arise in the
"unstable" distribution.

The aforementioned "prerelease" distribution can be aimed toward these
users, as it is to be regularly updated, but will have stronger
testing requirements than "unstable". To ensure this, it seems
sensible to require that packages must have spent a suitable amount of 
time in the "unstable" distribution before being considered for the
"prerelease" distribution.


 a) The "stable" distribution
     This distribution is the official release of Debian, and is
     thus required to be as bug free as possible, current to within
     a few (3? 6?) months, and reasonably resistant to short term
     Its primary distribution method is expected to be by CD, and
     as such security updates need to be easily visible, both via
     dselect [or apt] and via more standard methods such as the
     This must be a complete distribution, with bootdisks, a
     bootstrappable base system, and an official CD set.
     Only severe bug fixes should be accepted to this distribution.

 b) The frozen distribution: this is only present
    intermittently; when the pre-release distribution is
    frozen, sublitted to testing, and becomes the next
    "stable" distribution. Even though testing happens
    throughout on the pre-release, frozen is where more
    intensive attention is given to integration
    glitches. Must be a complete distribution, as this is
    what becomes stable.

 c) The "prerelease" distribution

     This distribution will become the next release after freeze and
     testing (ie "stable"). It is thus required to only include
     packages that have already been tested to some degree, but should
     be updated regularly.

     This must be a complete distribution, with bootdisks, and a
     bootstrappable base system and an official CD set. The CD set
     should be updated on at least a fortnightly basis in an
     automated manner.
     Only tested packages should be accepted to this distribution.

 d) The staging area: This is an area where packages are
    moved to during the transition from unstable to
    pre-release; since we can't move a package from
    unstable to pre-release until all the shared libs and
    other dependencies are also ready to move into the
    pre-release area. This is *not* a complete

 e) The "unstable" distribution

     This distribution forms the culmination of all current
     development in Debian, and contains the latest version
     of every (non-experimental) package available. 

     This may be an incomplete distribution.

So the stages in a packages life are:

 1) packaged and uploaded to Debian, waiting in an Incoming queue
 2) checked out by dinstall, (lintian check here maybe?) the PGP
    signatures match, and goes into the unstable pool
 3) wait in unstable for a perirod. Resolve bug reports.
 4) When there are no (non wishlist?) bug reports reported, and the
    package is rellease ready in the maintainers mind, the maintainer
    tags it as such and asks that it be moved to the staging
    area. (suggest a minimum bug free stay in unstable before this is
 5) In the staging area, dependencies are checked, and more lintian
    checks maybe, and when all dependencies are go, move the package
    into the "unreleased distribution". 
 6) In the unreleased distribution, the package may undergo informal
    testing, and exposure to a wider user base.
 7) a snap shot of unreleased is frozen. By this time, no packages in
    the unreleased have any release critical bugs. They are formally
 8) the frozen distribution is released, and becomes stable.

        In Step 5, it is easier if we know which packageshave been
 deemed stable enough to move on ionto unreleased if there is a
 staging area, also, it shall be easier to focus on a package that is
 holding up other package (lib foo is still unstable, but packages A,
 B, and C have been in the staging area for 3 weeks. tiem to recompile
 the A, B, and C with older versions of XYZ, or to look at the problem
 with XYZ now).

Additionally, we need the following areas:

f) The "orphaned" repository

        Packages that are no longer being maintained, and have been
        withdrawn from release are stored here. Each package should
        include a /usr/doc/<pkg>/README.withdrawn describing why it
        was withdrawn.

*** is "withdrawn" a better name? AFAICT, packages in the orphaned
*** directory are more than just orphaned, they've actually been 
*** physically removed for one reason or another. I believe
*** "withdrawn" is the term used in the WNPP.

g) The "experimental" repository

        Packages that are in development, and are not considered
        stable by their authors should be placed here, until such time
        as they have developed enough that no crippling bugs are

*** this is separate from unstable in case there are packages like
*** dpkg, apt, fdisk or similar that the author/maintainer wishes to
*** let people alpha-test if they desire; but that aren't stable
*** enough to inflict on people who might not be expecting it.
*** I don't know if it's really appropriate for debian to be
*** distributing these though. Is http://master.debian.org/~whoever/ a
*** good enough distribution mechanism for such things?

Populating the Distributions


The unstable distribution is to be populated in much the same way as
the current unstable distribution is populated: by maintainers
uploading the latest versions of various packages, whether to fix
known bugs, or to introduce new features.

Packages uploaded to this distribution should be functional, and
should be reliable enough not to cause problems in regular
use. (Packages that fail this criterion should instead be uploaded
into the experimental area). Packages in this area may have "less
important" critical, grave or important bugs filed against them for an
extended period, where an immediate fix that does not remove
functionality is not available.

It is expected that packages in this area are in some form of
transitional period; and thus some care should be exercised in using
packages from this distribution.

We can perform some automated tests for release candidates; like "have
been in unstable for a month, and have no important or higher bugs
reported, amybe a release candidate ready for moving to the staging

Staging Area

This is an interim area where packages are moved to when the
maintainer feels they are stable enough to warrant being in the
pre-release distribution. One of the required contitions is that there
be no bugs associated with the package of important or higher
severity, also, it should have been in the unstable distribution for a
certain minimum period of time to ensure some exposure and time
required to detect possible bugs.

The package can only be moved to Pre-release when all its dependencies
are also either in pre-release, or ready to move into pre-release as

In normal circumstances, packages should only be selected after the
maintainer has expressed confidence in the package being suitable for
release, and the version to be added has been in use for a suitable
period. If the package is in the base system, it may not be added
until the base-disks is also update, and similarly, if the package
requires updates to any package depending on it, those packages must
be updated concurrently.

If the update is a security fix, or fixes a release-critical bug, the
release-group should add the package as soon as they are confident
that the package is basically stable (either by testing it manually,
or ensuring that the changes made are minor).

This are can swell when there are packages which are not compatible
across release boundaries. All packages involved in such Release
boundary incompatibilities shall be held here until pre-release can go
beyond that.

This may well be where we perform more stringent lintian tests, or
something, and we may use pkg-order or something of that ilk to
determine when packages move to prerelease status.


The prereleased distribution should be populated by selecting packages
from the unstable distribution that have already undergone superficial
testing, and that have no known release critical bugs. The pre-release
distribution should be complete in tiself, in the sense that all
dependencies have to be satisfied within the pre-release
distribution. (So it can be frozen and shipped ;-).

If a package in the prereleased distribution has a release-critical bug
discovered, then the package should be promptly fixed, replaced (with
an older version of that package from the package-pool) or removed (if
there is no releasable version of that package available). One of
these actions should be taken within a week of discovering such a bug.

It is expected that packages in this distribution should have
undergone some preliminary testing in all cases, and should thus never
have any problems with basic functionality, and that furthermore,
packages in this area should be continually undergoing more thorough
testing by the testing-group, to ensure that any obscure problems are
also discovered. 

Automated tests on packages in this distribution (such as ensuring
dependencies can be appropriately met, that a viable upgrade path
exists, that packages make secure use of temporary files, and so on
and so forth) are explicitly encouraged.


Since pre-release is constantly in flux, with packages moving in from
the staging are, we need to freeze a snapshot of pre-release, and do
consistency testing on that. This has to be a complete
distribution. Freezing and release are the responsibility of the
release manager.


The stable distribution should be populated by relabeling the current
"frozen" distribution at the time of release.

A "release" should only be made when the `release goals' are met, and
the packages within the distribution are tested to the satisfaction of
both the testing-group and the release-group. Thus packages in the
stable distribution should be reliable and as well tested as possible.

If a package in the stable distribution has a release-critical bug
discovered, then that package should be fixed as soon as possible, an
announcement made, and the package should be listed on an errata page,
for CD users.

New users are recommended to run the stable distribution, as it should
be the least likely to cause problems that they might be unable to

Experienced users are encouraged to run the prerelease distribution,
but should note that it may not have undergone as much testing as the
stable distribution.

Users who wish to help us avoid bugs as early as possible, and who are
able to cope with possibly severe instabilities are asked to run
[parts of] the unstable distribution and submit reports on the bugs
they find.

Developers are expected to run either the prerelease or unstable

Both the "stable" and "prerelease" distributions should have static
code names to facilitate following a particular release from
conception through release to demise.


/release/ is used to mean the staged releases of Debian. Debian 1.3.1,
Debian 2.0 and Debian 2.1 are releases.

/distribution/ is used to mean a set of packages, along with the
bootdisk images that go together to make up the operating
system. Every release is a distribution.

/complete distribution/ is a distribution that is complete enough that
it may be used to install new systems, have CDs burnt based on it. A
complete distribution should include all the "standard" packages.

/section/ is used to mean one of main, contrib, non-free or non-us.

/release-group/ is the person/group responsible for selecting packages
suitable for release. If it remains as just a single person,
/release-manager/, remains the appropriate term (this document makes
no suggestions either way as to whether this is better managed by a
group or a single person).

/testing-group/ is the group responsible for testing installs, and
upgrades, and ensuring that packages selected for release are "up to

/release-critical bug/ is any bug that makes a package unsuitable for
release. The current criteria is a severity of important, grave or

/revoked/ is used to mean a particular version of a package is

/removed/ is used to mean all versions of a particular package is

 "Love may fail, but courtesy will prevail." A Kurt Vonnegut fan
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: