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
