Sean Whitton writes ("Bug#1106266: git-debpush: should possibly always
overwrite whatever is in the target suite"):
> When we designed the basics of tag2upload we considered it important to
> minimise the ways in which an upload might fail, that git-debpush would
> not detect. That's one core reason for always using split view. The
> idea is that if the maintainer has already pushed their tag to salsa
> then we should only fail if we discover a really serious problem.
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.
With tag2upload there is also the possibility of problems with orig
handling. For example, if you're reusing a .orig which doesn't
correspond to your upstream tag. I wouldn't be surprised if that was
fairly common :-/. By design t2u can't detect that because it doesn't
have the tarball.
I think it would be nice to detecct an NMU overwrite earlier, and/or
to report it more vigorously eg by having tracker.d.o to spot it.
I definitely don't want tag2upload to deliberately weaken a
correctness check just to avoid reporting errors at this stage. In
practical terms, the later mistakes are detected, the worse everything
is. Unconditionally overriding this check means detecting this
mistake *much* later, perhaps after Debian has released and an
original bug submitter experiences a regression.
I'm *hoping* that a tag2upload user who experiences this scenario
would thank us for detecting the mistake and giving them a chance to
correct it almost immediately. (And of course that they'll ask why it
couldn't be detected sooner, which is a good question.)
> I'm not sure that an unacknowledged NMU counts.
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.
> Indeed, it's fairly user unfriendly to have a debian/1.1-1 tag on
> salsa but the archive still has debian/1.0-9.1 and therefore your
> upload doesn't happen. It's not how Debian usually works.
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.
> 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.)
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.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
