On 02.12.2021 11:05, Junio C Hamano wrote:
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"?
One benefit that I see is that github offers APIs & Notifications around
releases and lots of CI integration already exist for it. If my (non github)
CI includes building the git source then i can easily trigger when upstream
releases a new version. Just pulling the repo and watching for the tag works
just as well of course.
However the "which source is genuine" is a valid objection. You certainly
don't want the CI to accidentally create a new release that does not exist
on kernel.org (yet).
