To: debian-devel@lists.debian.org Subject: Proposing self-regulating aging for testing migration Hi, A few years back, Russ Allbery and Lars Wirzenius proposed a number of suggestions to implement what was referred to as [Always Releasable Testing]. One of these suggestions was the "mini-freeze" whenever there were too many RC bugs in testing. This proposal is based on that idea but attempts to do it in fully automated fashion. # The essence of the proposal: * We propose that the release team adjusts the aging of packages depending on the amount of RC bugs based on a concrete proposal listed in the section "Age regulation method". * As the aging requirements increase, the migrations will slow down and in its extreme it will implement a freeze-like behaviour. On the flip-side, fixing RC bugs will make things move faster again, which we hope will promote fixing of RC bugs. * There will be some exceptions to the aging delay, so we do not delay urgent uploads, plus the release team can manually overrule the delay with an age-days/urgent hint for exceptions. * It will be 100% automated and self-regulated, so the basic maintenance of this will not require manual work from the release team. ## Expected exceptions / escape hatches There will be cases where uploads will be exempt from the self-regulating delay: 1) Any manual aging of a package by a member of the release team. - Trivial to implement. 2) Any upload with an urgency of at least "high". - Automatable (data is available) 3) Upload fixes an RC bug in testing. - Automatable (data is available) 4) Upload fixes a security issue - Automatable (needs to pull data from the security tracker). - Side-effect: we can list CVEs fixed by the migration. 5) Another upload fixing an RC bug in testing is waiting for this upload - Common cases automatable, but less trivial to add. Roughly, they are listed in estimated complexity. The initial deployment will include at least 1-3 and hopefully 4 as well. ## Age regulation method To keep it simple and to promote the shared responsibility, we propose that: * Every RC bug adds a minor delay to uploads (with the exemptions noted in the previous section) * We start with a lower delay (1d per 100 RC bugs) and over time increase it to (1d per 50 RC bugs). * With testing being on 442 RC bugs, this starts off as a 4 day delay and towards the end, it will end up as a 9 day delay. - For an urgency medium upload, this will be 9 and 14 days in total. * Please keep in mind that the end goal is to keep testing close to RC bug-free at all times. The delay should reflect how close we are from keeping that property. The additional aging requirement will be documented in the excuses for the upload. # Related work The work on [integrating autopkgtests] will also need to regulate the aging. We [announced several years back] that autopkgtests integration would imply a shorter delay for packages that had (successful) tests. There was also a suggestion during DebConf17 to have regressions in autopkgtests start off with an aging delay during the initial implementations. This would eventually be replaced by outright blocking the migration once the implementation was mature enough. On behalf of the release team -- [Always Releasable Testing]: https://wiki.debian.org/Debate/JessieReleaseProcess/AlwaysReleasableTesting [integrating autopkgtest] https://wiki.debian.org/debci/britneyIntegration [announced several years back] https://lists.debian.org/debian-devel-announce/2013/08/msg00006.html