Re: SONAME bumps (transitions) always via experimental
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
Reply to: