Control: tags -1 wontfix
Sean Whitton writes ("Re: Bug#1106266: git-debpush: should possibly always
overwrite whatever is in the target suite"):
> 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.
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:
> 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.
This reads to me like a kind of "trickle-down autonomy" theory, a bit
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 propose closing this as 'wontfix', given our disagreements, possibly
> until someone complains (which they may never do).
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.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> 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.
