Fosdem 2007
Luk Claes <luk@debian.org>

This talk is about testing, not about Etch :-)

• Packages are usually uploaded to unstable
• They enter testing after some rough testing
• Testing is declared stable from time to time (release)
• Experimental for packages not suitable for next release

• Packages are considered first after 2, 5 or 10 days
• Packages must be in sync on all release archs
• Packages must have not more release critical bugs
• Packages must not break any packages currently in testing, unless a newer version that doesn't break is going in at the same time

• Packages need to be approved
• Packages must not break any packages currently in testing, unless a newer version that doesn't break is going in at the same time

• Urgency is no factor
• In sync on release archs is to be checked manually

normal

Package is considered after 10 days

medium

Package is considered after 5 days

high

Package is considered after 2 days

critical

Package is considered after 0 days

• Built and uploaded for all release archs

• At least equal amount of closed and new RC bugs

• New in testing is no RC bugs!
• Ofcourse it's better to have less RC bugs

• Only about being able to install

• Not depend and conflict at the same time
• Dependencies all installable
• Library transitions: Going in at the same time

• Remove packages (from testing)
• (un)block packages
• Force packages
• Allow packages with cyclic dependencies to enter testing
• Change urgency

• Sometimes, packages are stuck together for testing migration
• Extremely bad in combination with buildd issues and library shlib bumps
• Lagging buildds create new dependencies on newer libs - longer waiting time

1. Discover soon
2. Avoid
3. Worst case do binNMUs
4. Coordinate in time with buildd maintainers and ftp-masters

• Never upload a package into unstable not meant for release!
• Look at a package's migration status before uploading

• Questions?
• Remarks

• Luk Claes <luk@debian.org>