https://debconf22.debconf.org/talks/47-investigating-a-tier-system-for-release-architectures/ $ gobby infinote://gobby.debian.org/debconf22/bof/tier-architecture-system Credits for coining the idea go to John Paul Adrian Glaubitz. Hopefully the following teams are represented ============================================= Ports Team Porters Release Team (elbrus) ftpmaster DSA Present in the BoF (please write your name): ============================================ - Paul Gevers / elbrus - Thomas Goirand / zigo - Matthias Klose / Doko - Ben Hutchings / bwh - Jonathan Carter / highvoltage - Roger Shimizu / rosh - Graham Inggs / ginggs - Christoph Berg / Myon - Jathan - Steve McIntyre / Sledge - Antonio Terceiro / terceiro - Guido Gunther - Didier Raboux / Odyx - Christoph Biedl - Faidon Liambotis / paravoid - Helmut and many more Current status (as elbrus understands it) ========================================= Ports only have unstable plus sometimes installer images at release time for some Ports are there for initial porting, once official, bootstrapping starts anew on DSA maintainer buildds. By request of ftpmasters, ports is also the place where former release architectures reside. What this discussion is not about ================================= Porting for tier II architectures still needs to happen by interested parties. This is no magical fix for broken architectures. It also doesn't want to shift the burden of fixing issues on tier II architectures to the package maintainers more than the current situation. What this discussion is about ============================= What could we mean with tier I and tier II (or even tier III?)? Where would we need to change things? How do we define `testing` for tier II architectures? Do we want this? Do we want this enough that we're going to work on it? The rest is open for discussion; where the text sounds authoritative, it's just elbrus' initial proposal. Difference between tier I and tier II ===================================== Consider tier I much like the current release architectures. Maintainers are expected to solve issues on tier I architectures (with the help of the architecture porters). Maintainers don't need to look into tier II architecture problems but are expected to take reasonable patches that fix issues on tier II archs. Issues on tier II architectures don't influence migration on tier I (or other tier II) architectures. Issue on tier II architectures will not cause autoremoval. This means that tier II specific issues are never more severe than important. Tier I is guaranteed to be stable with FTBFS bugs and other QA issues being release critical while such bugs on Tier II will only be classified as important (or lower). Being Tier I means, the architecture must have dedicated porters, Tier II means that the Debian Ports team takes care of the maintenance of the port, similar to what happens now with release architectures vs ports. Difference between tier II and tier III ======================================= A further distinction could be between architectures that may become release architectures in future (II) and old architectures that will never be release architectures again (III). This could also be based on supportability by DSA (see below). Identified issues and potential solutions ========================================= definition of testing for tier II --------------------------------- Ideas (not all are orthogonal): * never be ahead of tier I * keep tier II in sync (per arch) by autoremoving packages that go out of sync - for more than X days - and block other migrations (except for packages in the base set) * try to keep up with tier I as much as possible - but prefer packages and versions already in testing * the porter team can hint removal on tier II (per arch) - to enable migration of certain packages/version at the cost of those removed - to remove package that are broken on certain architectures * the porter team can block migration of packages/versions on tier II (per arch) - to prevent built but broken packages ending in testing (and eventually in stable) * maybe not have `testing` on some tier II (or tier III) * tier II (or III) can enable build profiles to drop support for features that are too expensive on porters time britney ------- * needs awareness of tiers -> either in one instance, or in the case of multiple instances they need to talk (possibly only unidirectional) * removal hints only work across all architectures * is britney allowed to remove per arch? * porter hints need proper confinement as they shouldn't influence tier I dak --- * mini-dak doesn't enable testing, need support in dak (challenged) - mini-dak also decrufts too eagerly * One dak instance or multiple? - We need synchronization of overrides and removal with cruft handling * How to handle binaries with different names on ports? - currently the porter team handles NEW for those DSA responsibility ------------------ * DSA is responsible for maintenance of the buildd servers (for tier I). * who is responsible for maintaining the tier II buildd servers? - can DSA take responsibility of the tier II buildd servers? - if not, how to switch between tier I and tier II - if not for all, maybe add a tier III for those that can not? i.e. tier I == current release architectures tier II == current port architectures where buildd meets DSA specs tier III == current port architectures where buildd doesn't meet DSA specs BTS --- * Add support for "RC for tier II" (to enable automatic blocking and removal) to think about mirrors and its size autopkgtest requirements? ftpsync script (aka: archvsync) ------------------------------- * Evaluate the extra needed space * Extra options: - to exclude tier II/III binaries - to exclude sources for packages that have migrated on tier I but have to be kept around on tier II source packages only needed on tier II Volunteers ========== * elbrus for support in britney Volunteers needed for ===================== * archvsync / ftpsync (see above) * dak * Need to formalize rules for an arch to be tier I, II or III * Add support for BTS to support RC in Tier II (ie: a bug in a specific tier >= II would not make the bug RC). - Could be architecture tags or general tier tags that effectively override severity Notes ===== elbrus discussed part of this with aurel32, bunk and jrtc27 on 22 April 2022 on #debian-ports