Constantly Usable Testing BoF
DebConf 10, Interschool Lab, 17:00
Hosts: Joey Hess and Lucas Nussbaum
Notes below collaboratively gathered in Gobby
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
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?
- 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?
- aj lucas paulproteus reinhard joey cjwatson zack dld gaudenz paulliu asheesh (publicity) bdale (deep thoughts)