Re: Go teams stance on tag2upload
> > 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.
Reply to: