On Sun, Sep 21, 2025 at 09:57:17PM +0200, Santiago Vila wrote: > On Sat, Sep 20, 2025 at 06:19:33PM +0300, Adrian Bunk wrote: > > Control: tags 1096377 + patch > > Control: tags 1096377 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for blis (versioned as 1.1-2.1) and uploaded > > it to DELAYED/2. Please feel free to tell me if I should cancel it. > > Ok, I have made a team upload based on that. Thanks for your work. > > However, there were unreleased changes in salsa that your NMU would > have erased. Had your NMU reached the archive, we would have to revert > those changes in salsa to keep history consistent.
That's not true. Similar to a MR you could make a commit based on the previous upload, and then merge this into your branch. I don't consider it my problem how your workflow and tooling handles NMUs, but there is no fundamental reason why it couldn't handle them smoothly. > So please use DELAYED/7 or DELAYED/14, such a short timeframe > (DELAYED/2) to double-check changes in a NMU is not welcome. I use DELAYED/14 or DELAYED/15 when the package is still in testing. But when I am trying to fix a 3 digit number of packages back into testing, then I'm not waiting a week for seeing whether builds and autopkgtests are fine. The Developer's Reference recommends even to upload without delay: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#when-and-how-to-do-an-nmu ... Here are some recommended values to use for delays: Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days ... > Thanks. cu Adrian
