From: Carlos O'Donell <carlos@redhat.com>
To: Ian Kelling <iank@fsf.org>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
cti-tac@lists.linuxfoundation.org,
Khahil White <kwhite@linuxfoundation.org>
Subject: Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.
Date: Thu, 25 May 2023 07:02:55 -0400 [thread overview]
Message-ID: <54f9b741-52a2-ced0-5a8f-1ed2475b4cb6@redhat.com> (raw)
In-Reply-To: <877csx8k7g.fsf@fsf.org>
On 5/24/23 17:53, Ian Kelling wrote:
>
> Carlos O'Donell <carlos@redhat.com> 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.
next prev parent reply other threads:[~2023-05-25 11:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 17:24 Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration Carlos O'Donell
2023-04-12 20:46 ` Konstantin Ryabitsev
2023-04-12 21:28 ` Brian Behlendorf
2023-05-19 21:00 ` Konstantin Ryabitsev
2023-05-22 14:37 ` Ian Kelling
2023-05-24 20:50 ` Carlos O'Donell
2023-05-24 21:53 ` Ian Kelling
2023-05-25 11:02 ` Carlos O'Donell [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-05-19 22:47 Joseph Myers
2023-05-22 10:11 ` Joel Brobecker
2023-05-24 12:44 ` Carlos O'Donell
2023-05-24 13:43 ` Siddhesh Poyarekar
2023-05-24 14:12 ` Carlos O'Donell
2023-05-24 15:18 ` Siddhesh Poyarekar
2023-05-23 17:38 ` Konstantin Ryabitsev
2023-05-23 19:34 ` Joseph Myers
2023-05-23 19:52 ` Konstantin Ryabitsev
2023-05-23 20:12 ` Joseph Myers
2023-05-23 20:21 ` Konstantin Ryabitsev
2023-05-23 22:12 ` Joseph Myers
2023-05-24 16:29 ` Konstantin Ryabitsev
2023-05-24 18:13 ` Siddhesh Poyarekar
2023-05-24 18:55 ` Brian Behlendorf
2023-05-24 21:27 ` Siddhesh Poyarekar
2023-05-25 11:06 ` Carlos O'Donell
2023-05-24 19:06 ` Konstantin Ryabitsev
2023-05-24 19:42 ` Joseph Myers
2023-05-24 21:12 ` Siddhesh Poyarekar
2023-05-25 11:12 ` Carlos O'Donell
2023-05-24 18:58 ` Joseph Myers
2023-05-24 12:11 ` Siddhesh Poyarekar
2023-05-24 18:44 ` Joseph Myers
2023-05-24 19:58 ` Carlos O'Donell
2023-05-24 12:57 ` Carlos O'Donell
2023-05-24 18:46 ` Joseph Myers
2023-05-24 20:19 ` Carlos O'Donell
2023-05-24 20:48 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54f9b741-52a2-ced0-5a8f-1ed2475b4cb6@redhat.com \
--to=carlos@redhat.com \
--cc=cti-tac@lists.linuxfoundation.org \
--cc=iank@fsf.org \
--cc=konstantin@linuxfoundation.org \
--cc=kwhite@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).