From: Carlos O'Donell via Gdb <gdb@sourceware.org>
To: Mark Wielaard <mark@klomp.org>
Cc: "gcc developers" <gcc@gcc.gnu.org>,
"glibc developers" <libc-alpha@sourceware.org>,
"gdb developers" <gdb@sourceware.org>,
"binutils developers" <binutils@sourceware.org>,
"Overseers mailing list" <overseers@sourceware.org>,
cti-tac@lists.linuxfoundation.org, "Zoë Kooyman" <zoe@fsf.org>,
"Karen M. Sandler" <karen@sfconservancy.org>
Subject: Re: Core Toolchain Infrastructure - October 2024 update
Date: Wed, 30 Oct 2024 08:32:09 -0400 [thread overview]
Message-ID: <3a2c2d35-3b86-4286-a393-5ec166659f92@redhat.com> (raw)
In-Reply-To: <20241030103912.GD28606@gnu.wildebeest.org>
On 10/30/24 6:39 AM, Mark Wielaard wrote:
> Hi Carlos,
>
> On Tue, Oct 29, 2024 at 06:02:03PM -0400, Carlos O'Donell via Gcc wrote:
>> Recent discussions on the glibc mailing list make it clear
>> that we need to expand and discuss more about our "why" along with
>> the "what" and "how" of these changes.
>
> Zoe wrote a good summary of that discussion back in July:
> https://inbox.sourceware.org/f20ce996-e9c6-4b6c-856d-eec6e14af26e@fsf.org/
> Has anything changed since then to address the issues raised by her
> and others?
Yes, that the CTI TAC needs to expand the discussion of the "why" to the broader
list of the project, and that starts by writing up (something I'm in the progress
of doing) the detailed notes for glibc, particularly why we would want to meet
any of the requirements (and which specific ones) for a secure software development
framework. I'm writing these notes up for the community to continue our discussion.
Then once we have the full "why" written down, list the pros and the cons of an
LF IT-based solution and alternatives, including Sourceware, and again "why" the
TAC recommends one solution over the other.
I can get down to specific requirements and possible solutions for them, including
things like securing logins with 2FA etc. Which *could* be solved by Sourceware
today possibly using Nitrokeys (open hardware and FOSS), for example.
Having all the details spelled out would allow Sourceware to make progress on the
same issues raised, and I can even file infrastructure bugs if that helps.
> I don't believe the community is helped by trying to set up yet
> another, corporate controlled, organization or doing some highly
> disruptive move of some parts of the services our projects are using.
My position here is that the costs of running secure and robust infrastructure are
quite high, and engaging directly with corporate sponsors like we have done before
is the simplest way to pay for FOSS infrastructure. CTI is exactly the same model
we have today, but with broader corporate involvement, instead of just IBM paying
for the current services. This engagement happens in a place where the larger
contributors are already engaged at the Linux Foundation.
Have you discussed with IBM and other larger sponsors to pay Sourceware PLC to
fund expanding the current services?
My deepest concerns here is that Sourceware PLC cannot convince larger sponsors
to provide the funding to do what needs to be done to scale out and improve our
services.
> I noticed you attended the Infrastructure BoF at the Cauldron and seem
> to be experimenting with the new Forge we setup. I hope you will be
> happy to work with the existing community and the existing
> organizations that support the GNU toolchain and the Sourceware
> infrastructure, instead of trying to setup yet another organization
> that would split our efforts.
I'm excited that the GNU Toolchain community is looking at different workflows and
solutions, but if I'm honest the same question of funding and service/workload
isolation applies.
I'm *more* excited to pay Codeberg directly to support the GNU Toolchain to support
the development of Forgejo, particularly given that larger groups like Fedora are
considering Forgejo.
Thanks for your feedback. We can continue the discussion once I post more to the
overseers list.
--
Cheers,
Carlos.
next prev parent reply other threads:[~2024-10-30 12:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 22:02 Carlos O'Donell via Gdb
2024-10-30 10:39 ` Mark Wielaard
2024-10-30 12:32 ` Carlos O'Donell via Gdb [this message]
2024-10-30 15:45 ` Mark Wielaard
2024-10-30 16:23 ` Karen M. Sandler via Gdb
2024-10-30 16:45 ` Joseph Myers via Gdb
2024-10-30 16:52 ` Carlos O'Donell via Gdb
2024-10-30 17:06 ` Joseph Myers via Gdb
2024-11-04 10:50 ` Mark Wielaard
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=3a2c2d35-3b86-4286-a393-5ec166659f92@redhat.com \
--to=gdb@sourceware.org \
--cc=binutils@sourceware.org \
--cc=carlos@redhat.com \
--cc=cti-tac@lists.linuxfoundation.org \
--cc=gcc@gcc.gnu.org \
--cc=karen@sfconservancy.org \
--cc=libc-alpha@sourceware.org \
--cc=mark@klomp.org \
--cc=overseers@sourceware.org \
--cc=zoe@fsf.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