On 2026-02-13 00:25:58 +0100 (+0100), Gioele Barabucci wrote: [...]
Is it really different from what you are already doing when you create the tarball? Currently someone has to:1. pick a commit, 2. tag it, 3. run a script to create the extra files, 4. put everything in a tarball, 5. sign it, 6. publish it. In the Git-only version steps 4, 5 and 6 would become: checkout -b v1.2.3-relase git add . git commit -m 'Release version 1.2.3'" --gpg-sign git push or: checkout -b v1.2.3-relase git add . git commit -m 'Release version 1.2.3'" git tag --sign v1.2.3-full git push; git push --tagsThe person doing the release would be the same, all constraints would be the same. But now the Git repo would have all the info that is in the tarball. (And the tarball could be generated via a simple `git archive v1.2.3-full`, with the extra assurance that it matches what is in Git.)
This is getting into the weeds of our workflow automation, but currently the system works like this:
1. A human chooses a specific existing repository state on a particular branch and submits a release request associating it with a particular version number.
2. Automation reacts to the request and generates a local tag, builds test versions of release artifacts and exercises them, then reports back on the request.
3. Human release managers review the request and test results, then approve the request if it's suitable.
4. Automation performs the testing from step 2 again (because external factors may have changed in the meantime), and then if successful pushes a signed tag into the official repository for the project as well as publishing other release artifacts (signed source tarball, language ecosystem packages, container images, et cetera).
Setting aside that the project maintainers are very hesitant about committing generated files into revision control (we accept that it's necessary in some cases, like translations extracted from a separate community-operated string translating platform and massaged into gettext/babel/whatever for inclusion into the projects), I think your proposal basically implies additional sub-steps between 3 and 4, namely:
3a. Automation makes an API call to the review platform creating an ephemeral release branch, creates a patch containing the generated files and pushes them into the review system targeting the ephemeral branch, tests the results of applying the patch and reports the test results to the review system.
3b. Human reviewers inspect the patch and test results, then approve if acceptable.
3c. Automation re-tests and merges the generated patch to the ephemeral branch.
Also after automation signs and pushes the tag in step 4:4a. Automation creates a merge commit to tie the tag from the ephemeral branch back into the actual target branch, pushes that to the review system and tests it.
4b. Human reviewers check the merge commit and test results, then approve it.
4c. Automation tests the merge commit again and pushes it into the target branch if successful, then makes an API call to the review system to delete the ephemeral branch.
It's worth noting that in these projects, humans do not ever, ever push commits or tags directly into official repositories. Similarly, machines so not ever, ever push commits or tags directly into official repositories either without first being reviewed and approved by one or more humans. Further, there is always a final automated acceptance testing phase which occurs between human approval and machines pushing what was reviewed to the official repositories.
Beyond development of the additional automation and associated complexity surface area increase for potential new bugs, the suggested workflow change would involve two additional human review checkpoints (the commit with the generated files, and the merge commit back into the target branch), essentially doubling the amount of human involvement in the release process. This is then multiplied across hundreds of projects with developers requesting releases at frequent intervals.
-- Jeremy Stanley
signature.asc
Description: PGP signature
