Re: Enabling tag2upload for Debian Science Packages
Andrius Merkys writes ("Re: Enabling tag2upload for Debian Science Packages"):
> On 2025-06-18 00:52, Ian Jackson wrote:
> > The tag2upload system only does anything if you push a
> > specially-formatted signed tag containing a `[please-upload]`
> > annotation. These are typically made with `git-debpush(1)`,
> > which is the tool an uploader uses to invoke the tag2upload service.
>
> This is a very important point, thanks for clarifying.
...
>
> One more thing. It is great that a possibility is given to opt out.
> However, it creates heterogeneity within the team, and tag+push+forget
> might result in accidentally tagged, but never uploaded versions. Would
> it make sense to have a hook in opted-out repositories to send an email
> whenever tag with '[please-upload]' is received?
Obviously, it would be a mistake to make a please-upload tag for a
team upload for a package whose maintainer doesn't want that.
But, even so, this scenario is one reason I would recommend setting
the hook up for every package, where convenient. I think if someone
makes that mistake it would arguably be better for the upload to go
ahead than to leave a tagged but un-uploaded version on salsa.
Of course you may disagree. I think ultimately that's your decision.
(Some kind of warning, like you suggest, would probably be possible,
but setting up a webhook responder is not entirely straightforward.
That would be a programming project.)
> >> One feature that is not yet implemented and may be important to you:
> >> pristine-tar is currently unsupported. See bug report #1106071. If
> >> you have the interest, time, and expertise, feel free to contribute to
> >> its implementation.
>
> I rely on pristine-tar in my workflow. Therefore I am tempted to opt my
> co-maintained packages out to preserve my workflow.
Even though tag2upload doesn't currently support pristine-tar, I think
your workflow might still function correctly. The effect is simply
that the tag2upload service would regenerate the .orig.tar.* with "git
archive" rather than reproducing the original upstream one. (And this
would happen only with new upstream versions.)
I don't know what effect that might have for your future uploads; it
might mean you'd have to delete your local copy of the upstream
tarball and run `git-deborig`.
Regards,
Ian.
--
Ian Jackson <ijackson@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.
Reply to: