Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.

Carlos O'Donell <[email protected]> Thu, 25 May 2023 07:02:55 -0400
Newsgroups org.linuxfoundation.lists.cti-tac
Organization Red Hat
Message-ID <[email protected]>
On 5/24/23 17:53, Ian Kelling wrote:
> 
> Carlos O'Donell <[email protected]> writes:
> 
>> On 5/22/23 10:37, Ian Kelling wrote:
>>>
>>> GNU already has a system for release uploads to https://ftp.gnu.org that
>>> works very well and I help maintain it.
>>
>> Agreed, and I use it for glibc to upload release tarballs.
>>
>> However, the tarball release process is quite heavy-weight for release branch maintenance.
>>
>> In addition the downstreams sync from git release branch -> distro git to get the 
>> rolling release updates.
>>
>> So all the other discussions about trusting git become relevant here.
> 
> Yes, that all makes sense to me.

Just for clarity, and quoting again from my service evaluation for glibc:
~~~
* Release tarballs (ftp upload of gpg-signed release tarballs)
  https://ftp.gnu.org/gnu/libc/
  * Use gnupload script to gpg sign uploaded tarballs.
   * Uses ncftpput to place files into /incoming directories.
   * Network ftp access required.
  * Managed by the GNU Project/FSF.
  * Migration notes:
   * No migration required, would continue to upload to FSF.
   * Longer term discussion to use something more advanced.
   * Though good to have a backup following kernel best practice.
~~~

I noted that no migration is required here, but a backup has value.
If the backup, kput, used my ssh key via gitolite then it's already
using something I have setup as a maintainer to access git.

Several of the GNU Toolchain projects today upload to sourceware.org
*and* gnu.org. After the upload is complete we have mirroring from
other sources. So only the service of "upload" during a release window
could be improved by having an alternative.

The longer term discussion point there is specifically about what I
raised there, that release branch maintenance via tarballs is much
heavier than needed. Upstream uses git. Downstream uses git. And we
want a git to git mirror-style setup. In Fedora we would call this
"source-git" (as opposted to "dist-git" which contains rpm spec
files and configuration information). Today we sync Fedora Rawhide
dist-git weekly from upstream glibc git in order to have weekly
CI/CD. This conversation is something I can have with the GNU Project
and attempt to document best practice.

-- 
Cheers,
Carlos.