Hi release team, On Wed, Mar 13, 2024 at 10:55:09AM +0100, Helmut Grohne wrote: > I propose April 11th on the condition that all relevant packages > (including cryptsetup and e2fsprogs) have migrated. I'll also check with > Aurelien on feasibility after Easter.
Stuff wasn't ready back then and we kept bumping the /usr-move back. I think we need to fix dates soon. During the past months, I reserved time for the essential fallout and I cannot promise that in second-half-June, July and first-half-August. Meanwhile all the relevant stuff has migrated including the glibc upstream release. So we basically have the following options: * Pick a date before June 7th and go ahead soon. * Go for later and I'll handle the fallout best-effort. (i.e. similar t64 fallout) * Pick a date August 12th or later. Since noble includes these changes and I'd get this done sooner rather than later, how about moving forward with June 5th after 22:30 UTC (such that all buildds have regenerated their chroots before the upload)? There also is little to be done from the release team's side beyond installing a block for base-files, bash, dash, glibc, util-linux and then lifting the block once all of them are ready turn that block into a force hint such that they really migrate together. (There is no dependency relation between them ensuring concurrent migration as that would make upgrades more difficult.) Other than the bootstrap matter, we're down to 350 affected packages and dumat is finding one to five issues per week most of which are undeclared file conflicts. As a result of the dumat work, I haven't seen an actual end user report about a /usr-move problem in quite a while. A list of affected packages is at https://subdivi.de/~helmut/usrmove.ddlist (not entirely current). I'll propose a MBF for the remaining no-change sourceful uploads as well as the remaining "Build-Depends: dh-sequence-movetousr" uploads. All other moves already have bugs. I also plan to bump the severity of these bugs to important soon. Do you also agree with bumping these bugs to serious severity once their number goes below 200? Keep in mind that they are all actionable in the sense that one of the following applies: * No-change sourceful upload fixes * An upload adding "Build-Depends: dh-sequence-movetousr" fixes * The attached patch fixes * Rarely maintainer feedback has been requested Chris has already performed a number of NMUs and we'll need to do some more to eventually get us down to 0 aliased packages. A while ago I removed 10 affected source packages that were FTBFSing for two stable releases already. Helmut
