Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> Rather than hardcode given repositories, which e.g. for testing the CI >> itself can be bothersome, perhaps a better thing is to put this into the >> existing ci-config? I.e. git/git.git could opt itself in to behavior >> that would be off by default? > > You probably missed that the purpose of this workflow is something that > does not make sense in the forks of git.git. > > Its purpose is to create releases for all tags that are pushed to the > repository. Most forks of git.git have no business creating releases, and > those that do already have their own processes in place. > > As such, the situation is very different from the CI/PR runs that some > contributors might want to restrict to only certain branches in their > forks. All true. But https://github.com/git/git/ itself has no business creating releases, as we already have the release process that pushes the release material to kernel.org to be distributed from there. So... do we still need to discuss this patch? In other words, what's the benefit of creating "releases for all tags that are pushed to the repository" there? Does it give us redundancy in case kernel.org goes down? Does it risk confusing users having to wonder release materials from which source is more "genuine"?
