Constantly Usable Testing BoF

DebConf 10, Interschool Lab, 17:00
Hosts: Joey Hess and Lucas Nussbaum
Notes below collaboratively gathered in Gobby

Mission statement

Turn testing into something that our advanced/experienced users can use (constantly), possibly by creating a different "suite".

Q: Typical use cases?

  • Debian for the most recent hardware (kernel, Xorg, ppd, etc.)

Q: Should we make "releases" by snapshotting testing?

Q: Which level of support/"guarantees"?

Q: What makes current testing unsuitable?

  • main goal of current testing: create stable releases
  • installer doesn't always work
  • RT removes important packages from testing
  • security support: difficult to keep up to date, but that's the only way to get security updates
  • transitions delaying packages migration to testing,
  • delayed migrations of important bugfixes, important packages removed from
  • testing due to RC bugs

Possible implementations

Take a snapshot when a subset of packages are at an acceptable standard.

Change testing to make it fit our needs

Create a new suite, next to testing

other possible implementations?

Implementation details


  • Snapshotting testing.
  • How to support upgrades from old testing snapshots to current testing?
  • Installability/usability of testing. Issues like important packages being temporarily removed due to RC bugs.
  • Does testing get enough testing? Would having users use CUT improve that and help the quality of stable releases, or the opposite?
  • new suite(s) = dists/ size increase (concern if frequently updated)
  • Will CUT suite need its own proposed-updates queue? Security update queue?
  • Possibly use volatile or backports to fix holes in the cut.


  • Is testing getting security updates frequently enough compared to stable to be able to be promoted to users as "secure"?
  • How much extra work would be involved in supporting periodic snapshots of testing?
  • How could having CUT help the security team, perhaps by encouraging developers to work faster on security issues in unstable/testing?
    • A security patch in CUT should be more "close" to the needed in stable... allegedly at least.


  • How would d-i install a snapshot of testing? (eg, some special temporary suite name)
  • Could having CUT releases of testing offload work that d-i is currently doing on beta releases? Or otherwise improve things by, eg, providing a snapshot for installation media to use?
  • Space/bandwidth/building of CUT CD images.
    • CD images tend to be useless.


  • CUT release team should check that last cut can be upgraded to the next cut


  • testing is really a crappy name for something we want users to use
    • cut 1
    • cut 2
    • final cut-1 (frozen)
    • final cut (the final release)
  • how do we make sure the goals of this "thing" don't conflict with Debian's goal of releasing stable releases?

cut team

  • aj lucas paulproteus reinhard joey cjwatson zack dld gaudenz paulliu asheesh (publicity) bdale (deep thoughts)