On 2024-08-03 12:20:09 +0200, Paul Gevers wrote: > Hi > > On 03-08-2024 11:58, Luca Boccassi wrote: > > > On the use of tpu: > > > Personally, until now I fail to see enough value of being able to > > > distinguish unstable and testing to give the package carrying > > > /etc/os-release a permanent exception via tpu. > > > > Thanks for chiming in - assuming for a moment that it is decided that > > the change will be implemented, do you see any technical obstacles in > > using t-p-u as proposed? > > The biggest reason I know against using tpu is that it currently isn't > receiving the same amount of testing (be it automatic (autopkgtest, > piuparts, in the future reproducibility) or human) as unstable-to-testing > migrations receive. For the automatic part, that's obviously a solvable > problem (and already on my todo list for YEARS), but currently not the case. > It also *always* requires human intervention by the Release Team. Another > issue issue with tpu is that binNMU'ing is more difficult (I assume that's > probably not very often relevant in the current case). I recall there are > more issues with tpu, but I have forgotten them. When I find them, I'll add > them.
To add to that: tpu is used for exceptional cases only. Cases where we deem the result of the upload more important than the additional work required of a release team member. Cases where we deem RC bugs potentially introduced by missing QA for tpu uploads less severe than the issue we are trying to fix in testing. Essentially, if it is not a critical bug (think xz incident critical), going through tpu during non-freeze time never happens. For a package that is part of the essential set, having all the QA tools checking the consequences of the inclusion of this a package is really essential. Skipping out on QA checks for an essential packages that would normally run for typical unstable to testing migration puts even more pressure on the release team to make sure that accepting the package from tpu does not severly break testing. (As side note: in essentially all cases where I handled tpu uploads (that I remember) during non-freeze time, it was more effort to untangle unstable so I have asked maintainers explicitly to perform tpu uploads.) Also, we have been pushing to keep testing and unstable as close as possible. Packages not migrating for some time are considered RC buggy to reduce the difference and where Paaul is thankfully filing the corresponding bugs. Going through tpu would essentially introduce a package that is auto-RC buggy in the essential set with consequences: it causes even more divergence for autopkgtests in testing (reference tests), in testing + pinned packages from unstable for migration checks and in unstable. That would cause potentially even more work (for the RT and maintainers) to figure out why some test is failing in one configuration and not the other. But keeping all of that aside, I don't see any label that could be included as a static file in a package that would be correct due to the duality of testing. trixie is defined by what we release on release day. Labelling it trixie before that would be wrong as there are cases where creating a "trixie" image before release will not end up with a trixie image as produced after the release (just install something that is later removed from testing). It would be labelled incorrectly as trixie if users created it with testing or as testing + unstable. Any users may add experimental to the mix as testing + sid + experimental which would also be mislabelled. Without checking the apt configuration (including the Default-Release setting) and its sources configuration, there are always cases where the label is incorrect during our typical release process (and even then priorities may make it impossible to label properly). Labelling testing as $selected_release_name/sid is a good enough and more importantly an established compromise to label what will become the next release up to the freeze. So far I do not see a good enough reason to side-step typical migration flow from unstable to testing for a label for testing that won't be correct for one or another use case. Cheers -- Sebastian Ramacher
