On 2024-06-16 2 h 23 p.m., Russ Allbery wrote:
For the existing source package signatures, a simplified sequence looks
like this:
human --> (1) dpkg-buildpackage --> (2) debsign --> (3) archive
For tag2upload, a simplified sequence looks like:
human --> (1) Git --> (2) tag2upload --> (3) debsign --> (4) archive
Please excuse my naiveté, but how do you actually know that your package
"works" with the tag2upload workflow if you're not building anything
locally before pushing?
By "works", I mean, how have you tested it will build and will pass all
the proper pre-upload tests?
On my side, I tend to work on a Git tree and when I'm happy with it I
use sbuild to:
1. build the source and the binary packages (and thus run build tests)
2. run Lintian
3. run autopkgtests
Only if all of these steps seem OK will I consider signing and uploading
the resulting source package (and yes, in reality what I actually intend
to sign is the Git tree I worked on).
Implementation notwithstanding, I'd be more than happy to have a "git
$something" replace my use of debsign and dput, but I am genuinely
curious to know why we would make it easier to upload something that
hasn't passed what I believe are important QA steps before uploading?
Andreas Tille already raised that point in another thread, but the
answer seems to have been that it's already possible. Incentivising such
a behavior doesn't sound positive to me.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
