On 23.06.24 21:13, Micha Lenk wrote:
Okay, but couldn't the existing git-based workflows get formalized and standardized without changing the way how you upload to Debian?
Note the plural, which is a large part of the problem.Yes they can, in fact most of them already are; that's the "dgit push-source" part.
Why is it so important to tie the support for so many workflows to the method how the upload is done?
From my admittedly limited PoV there are three answers to this.* Support for these workflows is *not* tied to the upload method. tag2upload merely (famous last word) intends to add an alternate upload method that happens to offload 99% of the work to build the source tarball(s) from the builder's machine to the t2u service.
* Using a pure git-based upload method allows the maintainer to prepare the upload without requiring Debian-specific tooling. Producing a new Debian release from a CI workflow becomes a lot easier when the CI system doesn't need to have a dgit installation; the situation becomes worse when the git workflow you want to use is not yet supported by the dgit in Debian Stable. In fact, your CI could run on top of Fedora. Or even MacOS.
* "'git push' to build" opens the door to further streamlining of the way our archive works. Why should we build from source tarballs when the very "git pull" command that's required for assembling these tarballs could simply be reused for the "debuild -b" step? Why should our builders need to wait for the periodic archive update cronjob? Do we even need the source tarballs in the first place, or is a possibly-redundant service sufficient given that's what our binary builders use anyway? Should we feed traditional uploads into dgit in addition to, or even instead of, posting them to our FTP servers? etc.
-- -- mit freundlichen Grüßen -- -- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
