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

testing migration: What each developer should know


The testing scripts (aka "britney") seem to be a "black box" for some
developers. The intent of this mail is to give some information to prevent
common misunderstandings.

outdated on some arches
"outdated" means for britney: There are different versions in unstable for
the release architectures (except for the architectures in fuckedarches;
fuckedarches is an list of architectures that don't keep up (in
update_out.py), but currently, it's empty). "outdated" has nothing
whatsoever to do with the architectures this package has in testing.

Consider this example:
foo      | alpha | arm 
testing  |   1   |  -
unstable |   1   |  2
The package is out of date on alpha in unstable, and will not go to
testing. And removing foo from testing would not help at all, the package
is still out of date on alpha, and will not propagate to testing.

However, if ftp-master removes a package in unstable (here on arm):
foo      | alpha | arm | hurd-i386
testing  |   1   |  1  |    -
unstable |   2   |  -  |    1
In this case, the package is up to date on all release architectures in
unstable (and the extra hurd-i386 doesn't matter, as it's not a release

Sometimes, the question is raised if it is possible to allow packages in
that are not yet built on all architectures: No. Just plainly no. (Except
if you maintain glibc or so, but then you probably know much more about
britney than this mail tells you.)

package removals
Sometimes, a package is removed to allow another package in: This happens
only to allow _another_ package to go in, that's ready in every other
sense. Consider e.g. that a conflicts with the new version of b; than a may
be removed to allow b in.

Of course, there is another reason to remove a package from testing: It's
just too buggy (and having a single RC-bug is enough to be in this state).

circular dependencies
A situation that is not handled very well by britney is if package a
depends on the new version of package b, and vice versa.

An example of this is:
  | testing         |  unstable
a | 1; depends: b=1 |  2; depends: b=2
b | 1; depends: a=1 |  2; depends: a=2
Package a is not considered for update, and package b also not.

Currently, this requires some manual hinting from the release masters.
Please, send mail to debian-release@lists.debian.org if that happens to one
of your packages.

Of course, there are hammers. But, the goal of britney is that testing is
always in a releasable state, and if hammers are used too often, we'll
just void that. So, the hammers are not for everyday use, and just because
a hammer was used on another package, that doesn't mean that it'll also be
used on your package.

influence of package in testing
Generally, there is nothing that the status of a package in testing means
for transition of the next version from unstable to testing, with two
exceptions: If the RC-bugginess of the package goes down, it may go in
even if it is still RC-buggy. The second exception is if the version
of the package in testing is out of sync on the different arches: Then
any arch might just upgrade to the version of the source package;
however, this can happen only if the package was previously forced
through, or the arch is in fuckedarches.

In summary this means: The only influence that a package being in testing
has on a new version of the same package is that the new version might
go in easier.

If you are interested in details, this is how britney works:

1. The packages are looked at to determine whether they are valid
candidates. This gives the "update excuses". The most common reasons
why a package is not considered are too young, RC-bugginess and out of
date on some arches. For this part, the release managers have hammers
of any size to force britney to consider a package. (Also, the base
freeze is coded in that part of britney.) (There is a similar thing
for binary-only updates, but I'll not cover that in this mail.)

2. Now, the more complex part happens: Britney tries to update testing with
the valid candidates; first, each package alone, and then larger and even
larger sets of packages together. Each try is accepted if sarge is not
more uninstallable after the update as before. (Before and after this part,
some hints are processed; but as only release masters can hint, this is
probably not so important for you.)

If you want to see more details, you can look it up on
merkel:/org/ftp.debian.org/testing/update_out/ (or there in
~aba/testing/update_out to see a setup with a smaller packages file). Via
web, it's at http://ftp-master.debian.org/testing/update_out_code/

The hints are available via http://ftp-master.debian.org/testing/hints/
and the general information about the testing distribution is at
http://www.debian.org/devel/testing (and the information from this mail is
added soon to the web site).

   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Attachment: pgppeanOFdomu.pgp
Description: PGP signature

Reply to: