> > 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 > > I have seen so many broken source packages, that don't even build or > don't create the intended binary packages. I always check the binary > packages before I do an upload.
The above isn't the full workflow, I have omitted using local and remote builds on multiple architectures and ensuring CI passes etc. This just describes the point where I am certain the work is ready, and I merely finalize the debian/changelog to change e.g. "UNRELEASED" to "unstable" and tweak some entries. This does not describe the testing process, but purely the release part after all tests and reviews have passed. > > (wait 10-40 minutes until the FTP queue e-mail confirming upload happened) > > I can't remember when there was an issue with an upload ... > > > gbp tag --verbose > > gbp push --verbose > > ... so I am doing this right after the dput. In case something would > have gone wrong, I could move the tags ... It rarely happens, but I do run into it a couple times a year. In extremely unlucky cases of failed coordination among maintainers there could be a race condition between two maintainers uploading on the same time in a fashion that results in dual upload as neither git-buildpackage nor dput has built-in checks to warn if the version it works on is actually equal or lower to something already in the archives. Usually the rejections however are due to mistakes in version strings, wrongly formatted debian/changelog due to my typo/indentation error, or something that slipped the CI and all other testing and reviews. > > ..to: > > > > gbp dch --release --commit > > git debpush --gbp, > > Yes, but that doesn't look like that much of a relief. If it is about > typing you could have written a script. > Why is uploading and immediately tagging better here than in your first > workflow? Because I want the git tags to be as accurate as possible. I don't want to add a Debian release tag unless a release actually happened, so I choose to wait until confirmation before tagging. As the confirmation is an e-mail, I can't easily do a script to automate it. Maybe if I think harder, I might figure out some kind of "API" that a script could keep polling until upload is confirmed and proceed to automatic tagging. Also 100% of the repositories I work with use protected tags, so a standard workflow for myself can't rely on deleting/moving a tag. For me this boils down to do I want the tag to trigger the upload, or the upload to trigger tagging to happen. Outside of Debian every single project I have ever participated in has used the git tag as the trigger for the release, so the tag2upload initiative aligns with that principle. However tag2upload also has downsides e.g. it breaks the ability to easily audit the source code supply chain end-to-end, as dgit generates fake source packages when checksums don't match with upstream. Also I would really like the git-recieve hook on Salsa to check that CI passed before accepting a Debian release tag. Thus I am on the fence and grateful to read your viewpoints.
