Re: [PATCH] githubci: add a workflow for creating GitHub release notes

[Fabian Stelzer <fs@gigacodes.de>]

On 02.12.2021 11:05, Junio C Hamano wrote:
>Johannes Schindelin <Johannes.Schindelin@gmx.de> 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).