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

archive

• 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.

security

• 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.

installation

• 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.

upgrading

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

marketing/social

• 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)