On 2026-02-12 00:15:33 +0100 (+0100), Gioele Barabucci wrote: [...]
all the additions found in the tarball are generated automatically I assume. Why can't they be simply added to the Git repo while creating the tag in a classic "Releasing version foo" commit? (A common pattern in Debian's Git repositories because of the need to update d/changelog when doing a new release.)
Committing file changes in the working tree adds a new Git commit to the branch, which means a new branch state. In a highly-active project where you can't guarantee specific commit ordering and don't want to lock repositories for periods of time to quiesce development activity, that's a non-starter. Shades of Gödel Incompleteness, the point of versioning in our case is to indicate a point in time for a branch, and committing a version number into a file changes the state that version would refer to.
Essentially, our solution is that we attach versions and make releases retroactively, based on a specific repository state that was tested, we don't version in advance without knowledge of what other commits are going to end up in that version (due to asynchronous work between developers, coordination is a bottleneck and anywhere we can reasonably eliminate it we do in order to not hamper throughput).
Yes, the info in these extra files is going to be outdated soon, but you can always preface them with something like "list of authors as of v1.2.3".
The point being, we don't necessarily know who the authors are until we tag the release, and accurately updating an AUTHORS file in the branch would have to happen after the tag is applied which means the updated file wouldn't be included in that release.
Also, I understand that you have thousands of people contributing on the codebase, but do they all have push-access to the repository? Can't the person creating the tag announce that the new release is going to happen on day so and so? (Or do you routinely tag commits that are not the last on the development branch? That could be addressed by something like creating a release branch with only one commit containing these autogenerated files, merging the branch with the previous 1-commit release branch, and then tagging the merge commit.)
They work in parallel in a code review system, where maintainers independently approve patches or series of patches once they're ready, and then a gating CI system attempts to integrate their work and make sure that any separate workstreams don't break one another based on virtually-serialized (but actually-parallelized) testing that happens at merge time. Basically think of everyone's work as being thrown into a large hopper and then it falls through the grinder in a particular order where we test and then kick things out if they're going to break testing on the branch state (taking into account changes that queued up ahead of them at that time, as long as those preceding changes also pass testing).
What I really don't understand is: losing 1-to-1 correspondence with the git tree creates so many issues; is keeping this distinction really a net win for your project and projects with similar workflows?
Yes. To restate, coordination between humans is a bottleneck which slows the rate at which projects can progress on their work, and eats up time from humans which reduces their individual productivity. By reducing the degree to which humans have to coordinate their work with each other to just when it's absolutely necessary, and letting automated systems perform on-the-fly coordination for everything else, the pace of development is greatly improved.
-- Jeremy Stanley
signature.asc
Description: PGP signature
