Hello,

I had thought that the way tag2upload passes --trust-changelog to dgit
would mean that it would overwrite an unacknowledged NMU, like how dput
does.  It turns out I had forgotten some subtleties of how
--trust-changelog works and in fact what will happen is that the upload
will fail before it reaches gideon.

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 that an unacknowledged NMU counts.  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.

It seems worth noting that the NMU will still be on dgit-repos so we do
preserve it in some sense even if we switch to unconditionally
overwriting it.  WDYT, Ian?

Sean Whitton writes ("Bug#1106266: git-debpush: should possibly always overwrite whatever is in the target suite"):

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 don't like the phrase "unacknowledged NMU" for this.  "Lost NMU" is
fairer.  This is a data loss problem, not a lack of politeness.

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.

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.

Hello,

Sure, but the source in the archive is still updated in that case, which
is I think what people care about more, but ICBW.

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.

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.

If we unconditionally overwrote it we could make sure it was imported
and merged in at the point of doing so.

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).

Hello,

Errr, obviously 'git push' does.  But hopefully you see what I mean.

Sean Whitton writes ("Re: Bug#1106266: git-debpush: should possibly always overwrite whatever is in the target suite"):

git-push certainly makes network connections!  That's it's point.
As does git-debpush in the default mode of operation.

I'm not sure there's a difference in principle between making a
network connection before vs after.  But I do agree there's an
important difference between (a) talking just to the origin remote,
and (b) talking to other services, especially non-git services.


I did want to respond to one debate point you made:
like trickle-down economics.

And like I say I hope people will appreciate it when their mistakes
are spotted automatically, rather than finding it "offputting".


More generally, the underlying theory appears to be: because errors
(at this stage) are "offputting", checks shouldn't be made; instead
the software should just continue and do a wrong thing.

I find this notion entirely repulsive.  It's the ooposite of building
reliable and transparent systems.  It's the opposite of the kind of
software I have spent decades trying to build.

Let's not try to turn Debian into Microsoft Excel.  Let it be Rust
instead.  Let us hope that we have a community of careful programmers,
who appreciate it when a computer catches their mistakes, even if the
computer is more distant, and the detection later, than ideal.

I think tag2upload is quite slick enough without needing to make it
deliberately ignore errors and thereby deliberately cause data loss.

I've tagged it wontfix, but let's leave it open.  That lets other
people add their opinion, makes the bug report more discoverable to
people affected by this scenario, etc.

Ian.

Hello,

I don't think that an attempt to draw an analogy between antiegalitarian
capitalists and Debian package maintainers can succeed :)

Sure, but we are not building this software only for ourselves.
Many people in Debian have very different tastes and priorities to us,
and I don't think that it is right to characterise all those differences
in terms of caring less about errors, even if it seems that way to us.

In this case, someone might think that the maintainer's git repository
on salsa including changes tagged as released, but that have not been
uploaded, is a worse form of skew than overwriting an NMU.  In order to
avoid it, tag2upload should carry on, in that situation.

We have dgit for crashing immediately on any kind of possible error;
let's allow tag2upload to prioritise different things in order to serve
more users' needs.

SGTM.

Sean Whitton writes ("Bug#1106266: git-debpush: should possibly always overwrite whatever is in the target suite"):

The resulting state is a common out-of-course state in Debian, because
there are already many other reasons why there might be a tag on salsa
for an upload that never made it to the archive.

Some examples include NEW rejections, sponsorships, and even
networking failures.

The right way to deal with this is to the same thing as we do in all
these other cases:
 * Report an error to the uploader (as we do)
 * Have monitoring and QA systems (like tracker.d.o) detect it
   and display a warning about it.  (I don't know if they do.)

Ian.

Hello,

The comparison with NEW is apt.  After thinking about the example of
NEW, I'm no longer sure whether I would prefer tag2upload to always
overwrite NMUs or not.

People could reasonably disagree here, though.  If they think
overwriting an NMU is not much like NEW processing skew, then they might
want tag2upload to behave differently in this case in order to
prioritise reducing skew.