Toolchain Infrastructure project statement of support

Siddhesh Poyarekar
Sun Oct 23 13:27:26 GMT 2022

On 2022-10-23 04:59, Ian Kelling wrote:
> No, I don't think that was ever clear. I've just read this message, but
> I've been keeping up with everything public since Cauldron.  All your
> options assume that any specific service is 100% managed by LF IT, or
> 100% managed by sourceware. That is a bad assumption. They could do it
> together, or another group could help.  So, you said you wanted
> "dedicated ops management", and I assume sourceware is not currently
> equipped for that. But there is no reason that an ops team from LF IT or
> FSF could not provide dedicated ops management for existing sourceware
> services in collaboration with sourceware. Another notable ops team is
> OSU,

Hybrid administration isn't part of the GTI proposal, why would that be 
considered an option?  Is this something you'd like to propose to the 
TAC, i.e. give named members from the community access to infrastructure 
administration?  We can bring that up in our discussion with the LF IT.

> Anyways, basically, having a dedicated ops team does not imply removing
> the sourceware's role, it could simply mean: adding a dedicated ops team
> to sourceware.

Given that the current sourceware admins have decided to block migration 
of all sourceware assets to the LF IT, I don't have a stake on how 
they'd like to handle this for sourceware.  I could however, as a member 
of TAC (and as member of projects that have agreed to migrate to LF IT, 
i.e. gcc and glibc), discuss with others the possibility of specific 
community volunteers being given some amount of access to manage 

> To provide dedicated ops for the physical servers would require moving
> the servers or into servers in a data center near the ops team, or
> outsourcing the hardware management to one of many companies (usually by
> renting a physical server), but that is all totally feasible and not a
> big cost.
> Siddhesh Poyarekar via Overseers <> writes:
>> I want us to migrate
>> services to infrastructure with better funding (that's not just limited
>> to services),
> What do you want to fund specifically? "Infrastructure" and "not limited
> to services" is not specific enough to understand.
>> and an actually scalable future.
> What does "an actually scalable future" mean? That is very vague.

Both of those point to scaling hardware in addition to services, having 
things like physical isolation of services.  Scaling volunteers (which 
hasn't happened in the last 20-soemthing years; it has scaled *down*, if 
anything) and money to pay for dedicated ops isn't going to mostly 
pointless if we can't pay for hardware, which is owned by Red Hat. 
That, and FSF not being able to add resources for the GNU toolchain was 
in fact why we had to look elsewhere for funding.

I suggest you wait a day for the FSF hosted call so that the background 
is clearer.


More information about the Gdb mailing list