On Thu, 05 Jan 2023 at 12:26:09 +0100, Paul Gevers wrote: > The Release Team just asked ftp-master to hold of accepting SONAME bumps > targeting unstable to ease the last days before the Transition and Toolchain > Freeze. The Release Team would like to ask the ftp-masters to also by > default reject SONAME bump NEW uploads to unstable during the whole release > cycle and instead mandate they need to go through experimental.
That seems like a good policy, and many maintainers already do that, either because the new SONAME needs more testing before its transition or to make sure they can upload bug fixes to testing/unstable while waiting for NEW acceptance of the newer version (without risking those bug fixes being superseded by the new version at the unpredictable time that it gets accepted from NEW). The only potential problems I can see are: 1. It results in more uploads (to experimental and then again to unstable), which maintainers might consider to be a high cost for packages that only have a few tightly-coupled rdeps. I don't think this is really a big problem, particularly since passing NEW currently requires a source+binary upload but migrating to testing requires a follow-up source-only upload (same total number of uploads). 2. If there is already a version in experimental that is unsuitable for the next stable release, because there's only one experimental, in the rare case that upstream bumps the SONAME of the "old" branch, we can't do as asked. For example: - libfoo_1.0-1 (libfoo-1.so.0) is in testing/unstable - libfoo_2.0-1 (libfoo-2.so.0) is in experimental but not yet ready - maintainer wants to get libfoo 1.5 (libfoo-1.so.1) into testing/unstable This seems unlikely to happen often, because upstreams usually focus development of intrusive changes that can break ABI onto one branch at a time. Presumably if a maintainer finds that they need this, the ftp team would read a justification in debian/changelog and relax this rule? If bikesheds ever become available, then they would solve all instances of the "only one experimental" problem, including this one. 3. If the ftp team prioritize NEW review of unstable packages higher than experimental packages (do they?) then that would be counter-productive under the proposed policy, and they'd have to stop doing that (and perhaps prioritize binary-NEW higher than source-NEW, instead). experimental packages appear in red on https://ftp-master.debian.org/new.html, which makes me wonder whether that reflects those packages being de-prioritized, but perhaps I'm reading too much into that? smcv
