Re: SONAME bumps (transitions) always via experimental
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote: > Once accepted, > the proposed workflow should also become documented in Debian policy. As this is no technical policy, this belongs into the developers reference. However, please describe an actionable plan. What do you want to be rejected, in a codified form. It would be nice if you could provide a patch for process-new that displays this information. Bastian -- Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before", stardate 1312.9.
Bug#1026825: python3.11 as default
On 1/2/23 16:28, Graham Inggs wrote: qtbase-opensource-src is done, there's been no progress with PHP 8.2, but we can deal with mapserver and zeroc-ice if they become entangled. php-defaults got updated in unstable, now mapserver is BD-Uninstallable until php8.2 gets built on ppc64el & s390x which is going to take a while thanks to the massive Needs-Build backlog of binNMUs for the python3.11-default transition. What's your plan to deal with these entanglements? Hint mapserver out of testing? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Uploading linux (6.1.3-1)
Hi I would like to upload linux version 6.1.3-1 (possibly 6.1.4-1 instead) to unstable. Note this is aimed to be the kernel we want to use for Debian bookworm. An ABI bump is included. It is a new upstream version switching from the 6.0.y stable release to 6.1.y. Apart from switching from 6.0.y to 6.1.y there are additional changes covering: * Fix build regression in stage1 and pkg.linux.nokernel profiles * linux-perf: Simplify build-dependency on libbabeltrace-dev * linux-perf: Build with libzstd * linux-perf: Disable building with libdebuginfod * linux-perf: Update variable definitions to disable building with libbfd * [arm64] Fix/enable audio on rk356x devices * [arm64] Enable various Pine64's SOQuartz features * [arm64] Enable several Pine64's SOQuartz baseboards * [arm64] Backport rk3568-odroid-m1.dts file from upstream. * [x86] Enable X86_SGX_KVM (Closes: #1026174) * [arm64,powerpc*,s390x,x86] arch: Enable RANDOMIZE_KSTACK_OFFSET_DEFAULT (Closes: #1016056) * [x86] drivers/thermal/intel: Enable INTEL_HFI_THERMAL (Closes: #1026336) * lockdown: Correct mentioning of mode when LOCK_DOWN_IN_EFI_SECURE_BOOT is enabled (Closes: #1025417) * [x86] drivers/cpufreq: Change X86_AMD_PSTATE from module to built-in * [rt] Update to 6.1-rc7-rt5 * net: wwan: iosm: fix dma_alloc_coherent incompatible pointer type (Fixes FTBFS on armhf) * [arm64] drivers/perf: Enable ARM_SPE_PMU as a module * [arm64] drivers/perf: Enable ARM_DSU_PMU as a module * [arm64] drivers/perf: Convert CCN_PMU from builtin to a module * trace: Enable HIST_TRIGGERS for all kernels * [x86] drivers/hwmon: Enable SENSORS_AQUACOMPUTER_D5NEXT as module (Closes: #1019496) * [arm64] Drop "arm64: dts: rockchip: correct voltage selector on Firefly-RK3399" (never applied upstream) * [x86] drivers/hwmon: Enable SENSORS_CORSAIR_CPRO as module (Closes: #1023992) * [x86] sound/soc/intel/boards: Enable SND_SOC_INTEL_SOF_ES8336_MACH as module (Closes: #1014595) * [s390x] debian/config: Drop explicit enable of RELOCATABLE. * mm: Enable Multi-Gen LRU implementation (not enabled by default) * Enable CXL_BUS for amd64 arm64 ppc64el riscv64 (Closes: #1021998) * [riscv64] Set CONFIG_I2C=y to match most other architectures and fix an FTBFS due to modules ending-up in more than one package. * [riscv64] Improve Microchip Polarfire support: - Enable HW_RANDOM_POLARFIRE_SOC. - Enable MAILBOX and POLARFIRE_SOC_MAILBOX. - Enable POLARFIRE_SOC_SYS_CTRL. - Enable RTC_DRV_POLARFIRE_SOC. * [arm64] Enable ARCH_NXP. * verity: enable DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING * ima: enable ARCH_POLICY to let IMA check the status of SecureBoot * Enable CONFIG_INTEGRITY_MACHINE_KEYRING to load keys from MoK into the new machine keyring, trust by default and link into trusted and secondary keyrings. Refresh/drop obsolete out-of-tree patches. * [arm64] Enable ARCH_BCM to re-enable various RPi options * [arm64] Enable support for Rockchip rk356x devices (Rock 3A, Quartz64, Odroid M1, etc.): - Enable ARM_SCMI_PROTOCOL, COMMON_CLK_SCMI, RESET_SCMI. - Enable CHARGER_RK817. - Enable MMC_SDHCI_OF_DWCMSHC. - Enable MOTORCOMM_PHY. - Enable PCIE_ROCKCHIP_DW_HOST, PHY_ROCKCHIP_SNPS_PCIE3. - Enable PHY_ROCKCHIP_INNO_CSIDPHY, PHY_ROCKCHIP_INNO_DSIDPHY, PHY_ROCKCHIP_NANENG_COMBO_PHY. - Enable ROCKCHIP_VOP2. - Enable SND_SOC_RK817, SND_SOC_ROCKCHIP_I2S_TDM. - Enable SPI_ROCKCHIP_SFC. * drivers/net/ethernet/sfc: Re-enable support for Solarflare SFC9000 (Closes: #1022276) - Enable SFC_SIENA as module - Enable SFC_SIENA_MTD, SFC_SIENA_MCDI_MON, SFC_SIENA_SRIOV and SFC_SIENA_MCDI_LOGGING Several other changes and improvements around the packaging were done. There is the issue around https://lists.debian.org/debian-kernel/2022/12/msg00166.html which needs to be resolved for the bookworm release. Regards, Salvatore signature.asc Description: PGP signature
Bug#1026825: python3.11 as default
Hi, On 06-01-2023 07:39, Sebastiaan Couwenberg wrote: What's your plan to deal with these entanglements? I have bumped the priority of php8.2 on ppc64el and s390x as a start. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1004441: unblocking chromium?
Dear Chromium team, Security team, On 27-01-2022 17:15, Moritz Muehlenhoff wrote: On Wed, Jan 26, 2022 at 09:38:42PM +0100, Paul Gevers wrote: So, I'm proposing the following: we unblock chromium from testing, with the understanding that prior to bookworm's release, we have a discussion with the release team about whether chromium will be allowed in the stable release. This will allow testing users to upgrade for now, and then at bookworm freeze time we can figure out what will happen with chromium (and prepare the appropriate release notes if it will no longer be in stable/testing). What does the release team & others think of this? Sounds good! If the security team agrees with the message this is sending, I propose the following. We create an RC bug against release.debian.org (to make sure this issue is not forgotten, but not directly blocks chromium) with an "Affects: chromium", that clearly states that we postpone the decision. The decision will depend on how chromium updates (both in sid and supported releases) are handled between now and approximately the freeze. If we do this, don't get me wrong, I'll kick chromium out of bookworm again if there's no good track record before we release. Sounds good! It's about time we start discussing this. In your opinion, did the Chromium Team show enough track record to warrant chromium in bookworm during its stable cycle? From the raw number of uploads my first impression is yes, but I have no idea of the quality, how the communication went and those kind of details. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: SONAME bumps (transitions) always via experimental
On 1/5/23 12:28, Sebastiaan Couwenberg wrote: On 1/5/23 12:26, Paul Gevers wrote: Are there objections against this workflow? (Or voices from people who This has been a best practice for quite a while, high time to make it hard requirement. Kind Regards, Bas +1
Re: SONAME bumps (transitions) always via experimental
On Thu, 5 Jan 2023 at 08:28, Sebastiaan Couwenberg wrote: > > On 1/5/23 12:26, Paul Gevers wrote: > > Are there objections against this workflow? (Or voices from people who > > This has been a best practice for quite a while, high time to make it > hard requirement. I wholeheartedly agree here, at least in my experience.
Re: SONAME bumps (transitions) always via experimental
Hi! Il gio 5 gen 2023, 12:28 Sebastiaan Couwenberg ha scritto: > On 1/5/23 12:26, Paul Gevers wrote: > > Are there objections against this workflow? (Or voices from people who > > This has been a best practice for quite a while, high time to make it > hard requirement. +1 mfv
Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2
Hi Ondřej, On 21-12-2022 21:28, Paul Gevers wrote: The bump from 8.x to 8.2 is relatively painless, so can we schedule the transition in few days/weeks? Please go ahead. Ping. In a week from now, the Transition and Toolchain freeze starts [1]. The upload should happen before then, otherwise I'm going to withdraw the approval. Paul [1] https://release.debian.org/testing/freeze_policy.html OpenPGP_signature Description: OpenPGP digital signature
SONAME bumps (transitions) always via experimental
Dear all, 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. This requires a bigger audience to agree upon, hence this message. Once accepted, the proposed workflow should also become documented in Debian policy. The benefits of all SONAME bump NEW uploads going through experimental are at least: * disentangle the start of transitions from NEW acceptance by ftp-master * auto transition trackers [1] are setup before the start of transitions * reduce the chance of uploads accidentally interfering with ongoing transitions (by more awareness and exposure via tracker.d.o). Are there objections against this workflow? (Or voices from people who like this?) Paul [1] https://release.debian.org/transitions/ OpenPGP_signature Description: OpenPGP digital signature
Bug#1027959: transition: libkiwix
Control: tags -1 moreinfo On 2023-01-04 22:24:36 -0800, Kunal Mehta wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: lego...@debian.org > > Hi, > > I'd like to do the transition for libkiwix (and sibling libzim) in time > for bookworm, it's fully self-contained. > > I uploaded src:zimlib 8.1.0 to unstable last week, which unintentionally > had a breaking change in it (sorry!). libkiwix 12.0.0 is waiting in > experimental. If it had an ABI breaking change, you also have to do a transition for it. Please revert in unstable in the meantime and prepare the transition in experimental. Cheers > > Status of reverse dependencies for compatibility with new libkiwix+libzim: > * zim-tools: needs binNUM for libzim 8.1.0 > * python-libzim: fixed with 2.1.0, currently in unstable > * kiwix-tools: fixed with 3.4.0, waiting in experimental > * kiwix: fixed with 2.3.1, waiting in experimental > > > Ben file: > > title = "libkiwix"; > is_affected = .depends ~ "libkiwix11" | .depends ~ "libkiwix12"; > is_good = .depends ~ "libkiwix12"; > is_bad = .depends ~ "libkiwix11"; > > > Thanks, > -- Kunal > -- Sebastian Ramacher
Processed: Re: Bug#1027959: transition: libkiwix
Processing control commands: > tags -1 moreinfo Bug #1027959 [release.debian.org] transition: libkiwix Added tag(s) moreinfo. -- 1027959: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027959 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1027967: transition: tinygltf
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: tinyg...@packages.debian.org Control: affects -1 + src:tinygltf -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear release team, I'd like to squeeze in this tiny transition (pun intended). It affects Open3D only, which I successfully rebuilt on amd64 as usual. Theoretically, this could be combined with the binNMU for the Python 3.11 transition if that is not scheduled already. The ben tracker at https://release.debian.org/transitions/html/auto-tinygltf.html is okay. I realize that draco links tinygltf statically, so draco does not appear in the transition tracker, but I'd rather fix this in the draco package itself. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmO2rSEACgkQ+C8H+466 LVk3twwA7UBUkvUyFjDHsaGEnd6eeLDB7pz+zBU2W60xk8djA1KMAM9ocO2snBaH 1Gwsor2pQuHekRvT21aOOl5nvamvgTE9IfUdO9bPme9QDzO+19NHGaqsNWzgJEWU 82CcdQORRC9XGB2PRBEgFGbde+4CuhrOjZCuD2Zrx3c6IJ4lb/Hfl5664Jvh10pj TUCUqrkAtpS3UwMdn2C0RgIs+ISS+LTqjNZVdFkuy9/GoieDelmOcUKgejtd44WT CbQ0L4gi1kTOYt9aZAmXx3DMwrwujdv8j0+mDZu3g4ocDOJngQbeWb1/iJm+fVzg mGkTiacne8XViQN/MseYGHxijdk5pBKnEQhr/AmcYzkOxhR8XaJAvcwHTRl+oY1H TjFZKFpubZCsH1uWimo43O0wfM7HUPYnJB5nyjl0uQbbW4OP4GivsfTNvzF1uMCA JeiUldGlgvxVvU33jwd0j8/l8NgCQFMgYFFauHh2nW+V2JycEDRFiozhfbF1knk6 u6NblzGY =h0Us -END PGP SIGNATURE-
Processed: transition: tinygltf
Processing control commands: > affects -1 + src:tinygltf Bug #1027967 [release.debian.org] transition: tinygltf Added indication that 1027967 affects src:tinygltf -- 1027967: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027967 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: SONAME bumps (transitions) always via experimental
On 1/5/23 12:26, Paul Gevers wrote: Are there objections against this workflow? (Or voices from people who This has been a best practice for quite a while, high time to make it hard requirement. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1026392: marked as done (transition: gnat-12)
Your message dated Thu, 5 Jan 2023 11:00:48 +0100 with message-id and subject line Re: Bug#1026392: transition: gnat-12 status update has caused the Debian Bug report #1026392, regarding transition: gnat-12 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1026392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello. The gcc-V source package builds the Ada compiler (gnat-V) and companion library (libgnat-V). The default Ada compiler is selected by the gnat package. In unstable and testing, gnat Depends: gnat-11. In experimental, gnat Depends: gnat-12. Most Ada packages are currently removed from testing because of #1020018 (in libxmlada, a quite common indirect build-dependency via gprbuild) (fixed by this transition). Ada libraries have specific requirements. * They must Build-Depend: gnat (>= V) gnat (<< V+1). * Each -dev package name carries a version, similar to the shared object version for lib packages. Most changes in the source require a renaming of the -dev package, and a source upload of all reverse dependencies. In order to reduce the number of such transitions, many unrelated changes, like new upstream releases, are introduced with a libgnat transition and tested in experimental. * Each -dev package depends on both gnat and gnat-V. GCC builds no libgnat-V-dev package. The sources for the Ada standard library are distributed with the compiler in the gnat-V package. So it is convenient to track the transition with the libgnat-V package instead (even when the ABI is unchanged). Ben file: title = "gnat-12"; is_affected = .depends ~ "libgnat-8" | .depends ~ "libgnat-9" | .depends ~ "libgnat-10" | .depends ~ "libgnat-11" | .depends ~ "libgnat-12"; is_good = .depends ~ "libgnat-12"; is_bad = .depends ~ "libgnat-8" | .depends ~ "libgnat-9" | .depends ~ "libgnat-10" | .depends ~ "libgnat-11"; libgmpada https://buildd.debian.org/status/fetch.php?pkg=libgmpada=i386=1.5-1=1661971646=0 libgnatcoll-db https://buildd.debian.org/status/fetch.php?pkg=libgnatcoll-db=mipsel=23%7E20220814-1=1661841082=0 - are removed from testing because of #1020018, - are updated in experimental, but now fail to build on a supported architecture. I intend to - fill RC bugs against them in order to prevent their migration from unstable to to testing. - reupload them from experimental to unstable with the other packages as part of the transition (so that the versions depending on gnat-11 disappear from unstable) (and so that RC-buggy but mostly usable versions are available) - try to fix the issues after the transition is completed Is this the right way to proceed? adacgi adasockets ahven anet dbusada gprbuild gprbuild libalog libaunit libflorist libgnatcoll libgnatcoll-bindings libgtkada liblog4ada libncursesada libtemplates-parser libtexttools libxmlada libxmlada libxmlezout pcscada ready in experimental, removed from unstable plplot ready in experimental dh-ada-library gprconfig-kb ready in experimental (not Ada libraries, but connected and part of the transition) ghdl music123 are ready in experimental (not Ada libraries, but part of the transition because of dh-ada-library/8) These source packages produce no library and should only need a bin-NMU in due time: nmu topal_81-2 . ANY . -m 'Rebuild with gnat-12' nmu whitakers-words_0.2020.10.27-1.2 . ANY . -m 'Rebuild with gnat-12' nmu phcpack_2.4.86+dfsg-2. ANY . -m 'Rebuild with gnat-12' ada-reference-manual only requires gnat at build time and should not be affected. adabrowse adacontrol asis gnat-gps libaws are removed from testing because of unrelated RC bugs and should not block anything. --- End Message --- --- Begin Message --- On 2023-01-02 18:22:23 +0100, Nicolas Boulenguez wrote: > Package: release.debian.org > Followup-For: Bug #1026392 > > libgmpada > I have disabled the post-build tests on i386. Not proud of this > work-around, but #1026828 does not deserve an RC severity. > > whitakers-words > is fixed by an NMU and should migrate to testing within days. whitakers-words now migrated. So everything that was in testing, is now fixed. From a RT perspective, this transition is done. Cheers -- Sebastian Ramacher--- End Message ---
+1 (Re: SONAME bumps (transitions) always via experimental)
On Thu, Jan 05, 2023 at 12:26:09PM +0100, Paul Gevers wrote in a mail with the subject "SONAME bumps (transitions) always via experimental)": > Are there objections against this workflow? (Or voices from people who like > this?) I like this. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Everyone is entitled to their own opinion, but not their own facts. signature.asc Description: PGP signature
Re: SONAME bumps (transitions) always via experimental
On 2023-01-05 13:13:59 +, 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
Re: SONAME bumps (transitions) always via experimental
On 1/5/23 14:13, Simon McVittie wrote: 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. When I've needed experimental for an older version I filed an RM bugreport for the package in experimental. Being blocked by two ftp-master actions is not ideal, but it works. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: SONAME bumps (transitions) always via experimental
Hi, On 05-01-2023 14:13, Simon McVittie wrote: 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). To be fair, normal SONAME bump NEW uploads only need a arch:!all binary uploaded and normally the Release Team has been scheduling binNMU's for arch:!all binary uploads. So under quite some conditions it indeed does require an additional upload. Presumably if a maintainer finds that they need this, the ftp team would read a justification in debian/changelog and relax this rule? In my original mail I on purpose said "to also by *default* reject" (emphasis added now), exactly to not make it an absolute reject for purposes like this. Paul OpenPGP_signature Description: OpenPGP digital signature
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
