On 2026-02-13 21:40:07 +0100 (+0100), Gioele Barabucci wrote:
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. :)
[...]
I don't personally mind revisiting choices we've made upstream. The processes we have slowly evolved over time in response to observed challenges or a desire to optimize for minimal human time wasted (while being careful not to optimize away human oversight). If we discover things we could be doing (or not doing) to optimize this further then that's a net win, and small optimizations add up quickly at the scale our community operates.
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.
I think you're suggesting v1.2.3 would be the "clean" tag at the point on the original branch from which an ephemeral release branch is created, and then v1.2.3-release would be a "dirty" tag on the ephemeral release branch at the point after a commit containing generated files is merged?
This generated commit would still need to go through human review and approval before merging to the ephemeral branch, and then once merged the new v1.2.3-release tag request (auto-)proposed for review, reviewed and approved. I don't see a way to remove these checkpoints without allowing automation to merge unreviewed commits and push unreviewed tags.
Maybe the compromise you're hinting at is that because the generated files which get added/changed in release tarballs aren't being directly reviewed, and the orphaned v1.2.3-release tag is merely a representation of the corresponding tarball's contents within a Git working tree, any difference between the working tree at v1.2.3 and v1.2.3-release shouldn't need to be reviewed either?
It's an intriguing idea, though I can foresee needing to have a FAQ about why there are two tags for every release and which one is the "real" release tag. We consider tags and open branches as a kind of documentation of the state of the project, and are careful not to create stray tags or leave branches open once their corresponding stable release series reach end-of-life, lest consumers of those end up confused.
Alternatively, there's nothing that prevents downstream consumers from unpacking our current release tarball into a new local branch of the upstream Git repository and tagging that state themselves, which was one of the earlier suggestions in this subthread. I guess that's the fundamental difference: whether we do that step upstream at release time or someone does it downstream themselves later. From a cost/benefit perspective, it doesn't feel like a big win, but I'll give it some more thought, thanks!
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.
We need them if the generated commit is going to go through code review, because our code review system is the "source of truth" for our Git repositories, and requires an open branch as a target for a change under review to ultimately merge. If we give up on expecting prior review of those commits and whatever tags come after them, then you're right they wouldn't have to actually exist as named branches in the code review system.
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.
If following your suggestion to create "clean" and "dirty" tags for every release, this is true. The "clean" tags would appear on long-term branches while the "dirty" tags are orphaned and not merged back into any open branch before deleting the ephemeral branch.
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?
Yes, we review and regression test every state of the repository before it officially merges, with the idea that it should be always usable (modulo nondeterministic bugs, holes in regression test coverage, changes to external factors, et cetera). This is part of the reason for requiring the Git repository metadata instead of just the Git working tree contents, because we value the ability to have sortable development version numbers auto-generated based on an inspection of the tags present on that branch, SemVer signalling (major/minor bump indicators) in past commit messages, and so on. We similarly want release notes assembly to work correctly for unreleased notes present on the branch in commits since the last tag. All of this is inferred from Git metadata.
I think the only reason for downstream distros to care about our release tarballs is when they reject the idea of having a deep/full clone of our upstream Git repositories, which is the entire crux of this subthread.
-- Jeremy Stanley
signature.asc
Description: PGP signature
