It stemmed from the fact that often releases tars might not be exactly the same as asking git to do a tarfile. For example releasing Python packages may require a build step and installing from PyPI or a git repo is sometime not the same.
In fact there's an active discussion right now on debian-devel about maybe changing the norms to prefer VCS archives to upstream release tarballs (and rerunning any of the code generation steps like autoconf as part of the Debian build): https://lists.debian.org/debian-devel/2021/08/msg00133.html
... Also, the tooling not only expects a tarball, it expects every tarball with the same name to be bit-identical. So if foo 1.0 is already in Debian, you'd better not generate a slightly different foo-1.0.orig.tar.gz when you do a packaging update but you're still packaging version 1.0 of the upstream sources. In 2007 a tool called "pristine-tar" showed up to allow you to compute just enough information to regenerate the actual foo-1.0.orig.tar.gz from the foo 1.0 VCS tag and commit that delta onto a separate VCS branch. It's a pretty crucial but extremely finicky part of most workflows involving maintaining Debian packages via a VCS. And then it turns out that the author of pristine-tar actually was somewhat trying to "point out absurdities in the way things are done" (https://joeyh.name/blog/entry/twenty_years_of_free_software_...) and people just happily adopted the tool and made things more absurd.
When possible I try to have reproducible builds (https://reproducible-builds.org/) that respect SOURCE_DATE_EPOCH extracted from the commit datetime. At least for IPython I alway build twice to make sure the sha is identical.
I'd also be happy to have a way to signal to debian that there is a new release instead of having QA watch have to scan things regularly.
That would be great! Unfortunately the current forging model is very centralized, centered around the UX of private companies with their internal teams and little (if any) outside cooperation. That's why we need decentralized forging systems: https://staticadventures.netlib.re/blog/decentralized-forge/
There's an ongoing 5000€ bounty for implementing ForgeFed federation (based on ActivityPub) on top of Gitea, in case you know people familiar with golang/ActivityPub who'd like to help.
Also worth noting, i feel like there is room for experimenting with anti-authoritarian forging where you don't need upstream permission to receive webhooks (or other update notification). I've started experimenting with this but still pre-alpha quality: https://thunix.net/~southerntofu/forge/
> All of these CI/CD plateforms consider the repository itself should contain the tasks to be run, for example in a .gitlab-ci.yml file. This top-down deployment model is well suited to an organization controling the whole of its software supply chain, but is a severe restriction to 3rd party involvement, which mostly hinders volunteer-run projects.
> The forge suite adopts an opposite approach, where anyone can receive updates from remote repositories, and run the tasks they wish. This allows anyone within or without your projects to setup new test suites, benchmarks, and integrations. The applications are endless and should benefit your projects in many ways.
The tooling and community around reproducible builds is growing all the time, and imo we should be insisting on it for things such as government apps.
Note that vcswatch doesn't actually scan upstream repositories, just Debian packaging repositories.
In my Linux distribution, if something doesn't have a release tarball then I do something similar to "pristine-tar" to create the synthetic version that's stable over the decades (since I may need to rebuild the same software 10 years into the future). This is done through an HTTP-based service so I can fetch the result as if it were a tarball, and use all of the caching (by hash, see [0])as a result.
Release tarballs are VASTLY preferred for this reason.
Languages that try to "help" by circumventing this -- making reproducible builds into the future difficult -- have special helpers which go and fetch the resources (again, as serialized, checkable, hash-able objects) and make them available.
Some projects also attempt to download things from the Internet during the "build" phase of the project, so I created a tool to drop network access during that phase as well [1].
[0] https://hashcache.rkeene.org/ [1] https://chiselapp.com/user/rkeene/repository/bash-drop-netwo...