Hi Jeremy,
thank you for taking the time to describe in more detail your workflow.
Russ said in a reply to your email «we should not be trying to talk
upstreams out of this sort of thoughtful approach». He is right.
Nevertheless, please allow me to try to talk you out of your approach
one last time. :)
On 13/02/26 19:47, Jeremy Stanley wrote:
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 --tags
The 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).
[…] I think your
proposal basically implies additional sub-steps between 3 and 4, namely:
I don't see why these extra steps would be needed.
In your Step 2 simple change "Automation […] builds test versions of
release artifacts and exercises them" to "Automation […] commits test
versions of the release artifacts, exercises them creates a release
artefact by `git-archive`-ing that commit", and in Step 4 have the
automation push two tags (v1.2.3 and v1.2.3-release) instead of just one.
The rest can remain exactly the same. No additional human involvement is
necessary.
Also, the release tags create implicit branches, you don't need to
create explicit branches if your automation is good enough at
manipulating Git objects. And you don't need to merge back anything.
These are leaf commits that just document the fact that a release has
been cut with certain generated files.
Another point that I haven't raised in my previous email: can developers
build your project starting from any commit?
If that is the case, why should Debian care about the generated tarball
at all, whose extra content does not have an impact to the functionality
of the built binaries?
Regards,
--
Gioele Barabucci
