Lee Garrett <[email protected]> writes: > On 16/06/2025 21:54, Nicholas D Steeves wrote: >> Lee Garrett <[email protected]> writes: >>> On 15/06/2025 20:57, Nicholas D Steeves wrote: >>>> Lee Garrett <[email protected]> writes:
>> And yes, you can of course be added to Uploaders for trixie! :) > > Ditto :) I'm happy to contribute in a team context with team uploads :) >> 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. > > I have pushed my changes to [email protected]:debian/borgbackup.git -b > lgarrett/debian/latest before I saw your mail. I'm fine with adding the > autopkgtests after the release via s-p-u. Thank you. I reviewed your work before reading this email, for time efficiency. > After seeing your arguments I propose the following changes slated for > 1.4.1-3: These aren't my arguments. I double checked with the release team to make sure that I wasn't being unusually harsh, and they said *no cleanup changes*. You had already made those changes by the time an unblock was requested; thank you, that's fine, and is totally normal for the tip of a debian/latest style development. This is why we need to create a trixie branch right now. Also, totally fine, and it supports your intent to move to DEP-14 style. I've apologised in advance for writing potentially demotivating things because most of what you're advocating isn't an unblock of 1.4.1-2 plus essential fixups, but for your work on debian/latest to be part of the trixie launch. I'm sorry, but it's too late for that. For the purposes of trixie, during the hard freeze, the basis of any further work must be the version in unstable (the package from the Debian Archive and end-user view). Meanwhile, I want to position you as a maintainer of borgbackup for trixie, so that you can make the case for your good work to be applied at a time when the release team will have the time to be receptive to it. > from lgarrett/debian/latest: > keep: > 1c797b44 Update metadata (Vcs-Git/gbp.conf) to point to trixie > branches I had to modify this because you added an unnecessary complication. Remember, the time to review must be as close to zero as possible. No future-facing cleanups at this time. I'd be perfectly happy if you erased me as committer, so go ahead and do so if you'd like. To do so, optionally do the following: fetch sten/debian/trixie $ git rebase --committer-date-is-author-date 710d730 push it someplace new Yeah, that's arguably a pedantic implementation detail, but I don't yet know your preferences about this sort of thing. If it looks good at that time, feel free to create your changelog entries and finalise the changelog. I will of course be happy to sponsor the upload. > bf30a142 Skip build tests when running with DEB_BUILD_OPTIONS=nocheck. > ^^-- this fixes the override in debian/rules. Before the change, some tests > would always unconditionally run, which is incredibly annoying when building > the > package. We could also pull it in post-trixie, but IMHO good to have now > already. Release team hard nack for trixie launch, but I acknowledge it's nice to have, and lamby especially appreciates it when people support both the "nocheck" and "nodoc" (I forget if that's what it's called) build profiles :) Adding support for "nodoc" is something else you can do on the debian/latest, since that's the development branch. > ff408906 Add borgbackup-doc lintian overrides This is correctness/cleanup, so nack. > 4450318b Typo fix This is minimal and meets the criteria of user-facing documentation (zero regression risk), and zero time to review. > 32994538 Bump Standards-Version (no changes needed) This is cleanup, so nack. It also takes time to review and isn't a simple "bump". > d1f6fd10 Add myself to uploaders > ^^-- add you, too I'm happy to do team uploads, for now, thanks :) > 62827af0 Switch packaging repo to DEP-14 layout. The important part of this is in your 1c797b44, which has been applied. The time to introduce the more extensive changes in this and 1c797b44 will be post-trixie-launch. > c0988a56 d/watch: Limit uscan to the 1.x releases How is this in a targeted fix that is relevant to a minimal change unblock for a frozen release? Uscan is for development. > from trixie branch: > 42061bca (origin/trixie, trixie) Git shortlog of Debian-facing upstream > changes > between upstream's… > ^^-- I didn't interpret RM's message as we should list all commits from > upstream > in the changelog. In the past, "New upstream release x.y.z" is enough, and we > already have that in 1.4.1-1. I understand it rather as "Don't do any changes > to > the package (debian/*) unless you have documented the reason, because we're > manually reviewing the debdiff and we'll rather reject it than ask follow-up > questions." Sebastinas was not ambiguous. No cleanups, minimal [necessary] fixes only, everything must be documented, and upstream's git shortlog is desired if it saves time with its usefulness rather than wastes release team review time with uselessness. > 75eb3450 Update debian/NEWS: Upstream introduced less alarming and easier to… > ^^-- this looks good. I was confused at first because the CVE was fixed in > 1.2.5, but I see that upstream simplified the upgrade procedure in the > following > bugfix releases. Full ACK! Excellent, I'm happy you understand its provenance and how this adjustment should have been made sooner. When thinking about this some more, I realised that I could have done better than copy and paste from the HTML docs, custom format them for clarity, and then minimise the diff (ouf this busywork was not fun!) So I've added a citation for clarity and to make it clean that we're not plagiarising upstream's docs. Cheers, Nicholas
signature.asc
Description: PGP signature
