Lee Garrett <deb...@rocketjump.eu> writes: > On 15/06/2025 20:57, Nicholas D Steeves wrote: >> Lee Garrett <deb...@rocketjump.eu> writes: >> >> Thank you for your work doing various cleanup. Are you aware that the >> release team may look at the diff and say "these are too many changes, >> so we're refusing the unblock"? In particular, how do you know that the >> proposed autopkgtests won't cause borgbackup to fall out of trixie due >> to new failing autopkgtests on arm64? Potentially requiring a second >> upload to fix the first, and a second upload...do you think that meets >> the criteria for the hard freeze? > > borgbackup is a key package, so it won't get removed unless a release manager > does it manually. IMHO, if the autopkgtests fail on arm64, it would be good > to > take a very close look why they fail, since this could very well mean that > borg > is broken on arm64.
Yes, this is what things look like from a borgbackup maintainer perspective, but the other side of things is that it will require multiple teams to look at why the release of trixie has been delayed for an potential autopkgtest issue in borg. I have additionally specifically asked the release team about this case. Autopkgtests should be enabled in experimental during the hard freeze, and post trixie release merged to sid. At this time we can use DebCI for experimental to inform us of potential issues in trixie. This might justify further targeted fixes, or the release team might defer the fixes to a stable-update after the release of trixie. >> The principle is thus: we want to unblock the package people have been >> using and the one whose behaviour has data on buildd, reprobuilds, >> DebCI, etc. Changes that don't have supporting data from these sources >> introduce risk, even if they're good changes! :) > > I don't intend to change the way the package builds. Currently, only > simplesession-nofuse is even running on debci, since tests with > isolation-container restrictions are skipped. Having better autopkgtests > ensures > that any regressions due to (build) dependency updates will be noticed. And > especially elbrus is happy when there are more autopkgtests. :) :) Yes, thank you again for working on this, and this is true for uploads to sid/unstable when we're not in hard-freeze, but it's too late for trixie now. I'm sorry if this is demotivating, but I've double checked with the release team, and at this point in the freeze cleanups are not ok, and even the addition of good things is too late. Now we only get to fix release-critical issues, make documentation changes that won't be translated, and add or fix translations. And yes, you can of course be added to Uploaders for trixie! :) >> I'm in the process of preparing a minimal fix to NEWS as well as >> documenting the upstream changes so that the release team can assess the >> potential risk of unblocking the release. I'll push to a debian/trixie >> branch. I will wait to upload until everyone hears back from you, >> because that's the collaborative approach. > > I'm happy to push my changes for you to review before upload. I'd wait with > the > debian/trixie branch until the release, to avoid debian/latest and > debian/trixie > to become out of sync. Sorry, it looks like I pushed to trixie rather than debian/trixie. Please don't move that to debian/trixie yet, because debian/trixie should be a protected branch. The reason I started a minimum changes branch is because I believed debian/latest was already inadmissible to trixie. I didn't see your latest (today's) changes on debian/latest. Would you please push them? Also, all changes must be fully documented, and all changes to trixie will need to be justified vis à vis the no-changes definition of a hard-freeze. Kind regards, Nicholas
signature.asc
Description: PGP signature
