Re: Go teams stance on tag2upload
Hi!
On Thu, 2025-06-19 at 14:57:42 +0300, Otto Kekäläinen wrote:
> > > how's the go teams stance on tag2upload?
> >
> > I don't see any advantage of tag2upload, so I won't use it.
I actually see disadvantages with it.
> You are the FTP Master in Debian, right? Why do you not see any
> advantages? The system seems seriously flawed if FTP Master thinks it
> has no benefits.
(I also don't think this is relevant? But in any case given how it was
pushed through, I would not see it as surprising if some archive admins
would not be convinced of its merits…)
> Personally, I am compelled by being able to change my current workflow from:
>
> gbp dch --release --commit
> git-buildpackage -S
> debsign *.changes
> dput ftp-master *.changes
> (wait 10-40 minutes until the FTP queue e-mail confirming upload happened)
> gbp tag --verbose
> gbp push --verbose
This workflow seems flawed though. For a repo that can be pushed to by
multiple people, if you upload before tagging and pushing, that means
someone else could end up pushing stuff, which then will be a mess to
untangle, or the history will end up being very confusing afterwards.
Even for repos where I'm the single person who can push, I always tag
and push everything, and only then upload. If there'd ever be a need
to upload again due to a reject, then I'd use a new revision for that.
In addition I always prepare source-only uploads but with a full
build («dpkg-buildpackage -us -uc --changes-option=-S»), so that I can
run stuff like lintian on everything, and install the packages and test
stuff locally, etc. I also do not trust having the source packages
signed by some machine elsewhere, where that source package has been
constructed from git by a mangling tool.
And as has been mentioned elsethread that sequence could be scripted
into a small local wrapper.
> ..to:
>
> gbp dch --release --commit
> git debpush --gbp
(This clearly does not apply to other people, and while I try to check
other tools to see how they do stuff, I strongly prefer to use the
bare minimum wrappers possible, so that I can dog-feed on them and feel
what are their pain points, and how they can be improved, and whether
features or functionality from higher level tools can be moved down in
the stack, to simplify our packaging stack, instead of having to keep
adding layers over layers of wrapping.)
(I also do not generally use dgit, because it messes up the git
history and has some funny ideas on how sources in a VCS should be
handled…)
Regards,
Guillem
Reply to: