Re: SONAME bumps (transitions) always via experimental
On 2023-01-05 13:13:59 +0000, Simon McVittie wrote:
> 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).
That's exactly the case which caused this discussion -- maintainers
uploading packages with SONAME changes that has only one reverse
dependency, but which are part of the ongoing Python 3.11 as default
transition.
Everybody wants to get their transitions done even if it's just one
reverse dependency. But at this stage of the release cycle, such actions
just cause delays in transitons if not coordinated with the release
team. In the worst case, we will have to block such transitions and ask for
a revert.
> 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?
>From recent memory and assuming there are no issues with d/copyright,
binary-NEW uploads to experimental have been processed swiftly.
Cheers
--
Sebastian Ramacher
Reply to: