Hello, On Thu 22 May 2025 at 11:14am +01, Ian Jackson wrote:
> I'm not sure I agree with this, at least, not put so strongly. > > There are already a lot of things that can go wrong after you do an > upload. Most notably the build or autopkgtest might fail. Sure, but the source in the archive is still updated in that case, which is I think what people care about more, but ICBW. > I don't like the phrase "unacknowledged NMU" for this. "Lost NMU" is > fairer. This is a data loss problem, not a lack of politeness. Yes, it's a lost NMU. It's just standard Debian terminology to use "acknowledged" for including the NMU in the maintainer's d/changelog. > I agree that this is not a great experience for the uploader. But the > uploader is not the only person in this picture. We also have the > original bug submitter (and their users), and the NMUer. > > I know Debian culture is to always privilege the Debian maintainer's > interests over everyone else's - that's kind of structurally > inevitable - but I don't want src:dgit to be that way. > > The biggest reason *I'm* doing all this is so that Debian can better > serve our users. We should always be primarily focusing on the > interests of the least powerful, which here means users affected by > bugs that led to NMUs, with patch contributors and NMU uploaders as > runners-up. > > So I'm afraid I must very strongly oppose your suggestion, on both > technological and ideological grounds. Well, we benefit users most significantly by getting people to upload with tag2upload because then 'dgit clone' provides the maintainer's history. And I think tag2upload is more appealing to maintainers the less likely it is to fail after the debpush. Each time someone gets a failure from the tag2upload service will be offputting. >> It seems worth noting that the NMU will still be on dgit-repos > > You mean it will be in the archive. It won't be on dgit-repos unless > it was done with dgit or t2u. (Eventually we'll want to import > everything onto dgit-repos which will improve this.) If we unconditionally overwrote it we could make sure it was imported and merged in at the point of doing so. > But, moving forward: > > I do have some ideas about how we could detect this sooner. > > A. We could have git-debpush fetch from dgit-repos. This would allow > early detection of overwrites of dgit- and t2u-based NMUs. > (The check would have to be like the dgit --trust-changelog one, > not be a git ff check.) > > B. The version number of the package currently in the target suite is > available from the ftpmaster API. > > I'm a bit hesitant about B because I don't want git-debpush to be > conceptually polluted with tarballs-and-patches, but really the > ftpmaster API call is just "distro + suite + source package => version > number" which could easily be served by a git-only distro setup. > Indeed, both A and B are ways of obtaining that version number. I'm uncomfortable about git-debpush making any network connections, because git-tag and git-push don't do that, and it's meant to be a thin wrapper around those two tools. I propose closing this as 'wontfix', given our disagreements, possibly until someone complains (which they may never do). -- Sean Whitton
signature.asc
Description: PGP signature
