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.