Many (all?) of GNOME’s modules are released as versioned tarballs, very much out of tradition, and because that’s the way distros preferred to work for many years.
I think distros have tooling to do releases from git tags these days; there are definitely packages in openSUSE that come from a project’s git tags. Do distros in fact support this well these days? Well enough to pick up git release tags from some GNOME library?
If not, would gitlab release artifacts work for them? They are basically tarballs straight from the repository’s files at a particular tag, as far as I can tell. They are not the same as autotools-generated tarballs, but I think distros have no problem in doing autogen.sh? I am not sure if meson dist is any different.
The problem with GitLab artefacts is that there is no guarantee that they are going to stay the same: Git does not guarantee that git-archive will work compatibly across versions of Git.
Additionally, release archives are built with meson dist, and that can use a dist script to include additional files; or --include-subprojects to ship with all the subprojects to avoid network connection while building.
Probably a better intermediate goalpost would be: maintainer pushes a git tag, release tarball is automatically generated, maintainer gets a mail if something goes wrong.
Having a CI template that builds a tarball against the GNOME run time would be good for most projects inside core, but would likely not be enough for projects outside it. It would also allow storing the release archive as a CI artefact, and even create a new release page using the GitLab API.
The important thing is that every release gets a predictable URL that we can pull from; if we can attach a release archive to that URL, then we only need a script that pulls the release archives at certain times, and puts them on download.gnome.org; alternatively, we need the CI to send a POST to a service running on download.gnome.org with the location of the release archive, and then that service can pull it.