Re: Archive Restructuring - Package Pool
Hi,
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?
BACKGROUND
==========
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
conclusion.
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
packages.
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
package.
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
year.
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.
DISTRIBUTION CHANGES
--------------------
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
change.
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
web.
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
distribution.
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
done?)
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
tested.
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
expected.
*** 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
----------------------------
Unstable
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
area".
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
well.
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.
Prereleased
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.
Frozen
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.
Stable
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
fix.
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
distribution.
Both the "stable" and "prerelease" distributions should have static
code names to facilitate following a particular release from
conception through release to demise.
TERMS
=====
/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
standard".
/release-critical bug/ is any bug that makes a package unsuitable for
release. The current criteria is a severity of important, grave or
critical.
/revoked/ is used to mean a particular version of a package is
deleted.
/removed/ is used to mean all versions of a particular package is
deleted.
--
"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: