git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Fabian Stelzer <fs@gigacodes.de>
Date
Dec 3, 2021, 08:33 UTC
Message-ID
<20211203083334.tziwuhbg2u4lsslt@fs>
In-Reply-To
<xmqqy252u8t7.fsf@gitster.g>
On 02.12.2021 11:05, Junio C Hamano wrote:
Show 29 quoted lines
>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).

Previous: Junio C HamanoNext: Junio C Hamano
Message 8 of 11 in “githubci: add a workflow for creating GitHub release notes”
  1. githubci: add a workflow for creating GitHub release notesMahdi Hosseinzadeh via GitGitGadget, Nov 25, 2021
  2. Matthias AßhauerNov 25, 2021
  3. Johannes SchindelinNov 26, 2021
  4. Matthias AßhauerNov 26, 2021
  5. Ævar Arnfjörð BjarmasonNov 29, 2021
  6. Johannes SchindelinNov 30, 2021
  7. Junio C HamanoDec 2, 2021
  8. Fabian StelzerDec 3, 2021
  9. Junio C HamanoDec 5, 2021
  10. Fabian StelzerDec 5, 2021
  11. Junio C HamanoDec 7, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.