Meeting Minutes - Office Hours for CTI - 2026-08-28

[Carlos O'Donell]

On 9/8/26 6:21 PM, Alexandre Oliva wrote:
> On Sep  8, 2026, Joseph Myers <josmyers@redhat.com> wrote:
> 
>> On Tue, 8 Sep 2026, Alexandre Oliva wrote:
>>> Our current voluntary hosting arrangements listen to and participate in
>>> the community.  If we want to try something out, they're normally happy
>>> to lend us a hand and make it happen.
>>>
>>> A professional hosting arrangement will involve a professional
>>> relationship, in which only designated parties will be able to submit
>>> requests in order to have them as much as listened to.
>>>
>>> This is not AT ALL in the best interest of the community.
> 
>> As far as possible, configuration changes for production infrastructure
>> *should* be slow and carefully considered, rather than just happening
>> because one community member thought a change was a good idea and one
>> hosting person then implemented it, possibly disrupting things for other
>> people, deviating from a previous community consensus or introducing a
>> security vulnerability.
> 
> Agreed.  Not at all my point.
> 
> My point is that in the current arrangement the community can discuss
> (in this mailing list) and come to an agreement, and then whoever the
> community appoints can take the request to the volunteer operators.

The same thing will happen today.

Instead of Sourceware volunteers it goes to the CTI TAC, which is still
volunteers, who review and request the change be made to the service
provider.

GNU Toolchain -> CTI (TAC, Board) -> Service Provider (LF IT)

GNU Toolchain -> Sourceware (Overseers, PLC) -> Service Provider (Volunteers)
> In the proposed arrangement, the community can discuss (in this mailing
> list) and come to an agreement, and then a shrinking fraction of the
> technical committee in the CTI that actually represents our community
> will perhaps take it to a CTI meeting and then maybe report back that
> they couldn't get approval to as much as issue a request.

The same can happen if Overseers rejects your request, or doesn't have
funding or people to implement it, or the Sourceware PLC rejects the
funding request.
  
> What twisted logic would make the latter better for the community?
  
Both models are very similar.

Sourceware is different in that it has *additional* governance goals
for infrastructure that the GNU Project does not require nor need.

If we use FOSS tooling and we can clone the repo, we are happy to have
sponsors provide our services using FOSS and support our projects.

Just like we don't ask our volunteers to believe what we believe, we
don't ask our sponsors to believe what we believe, but we do ask them
to use FOSS tooling for our services.

-- 
Cheers,
Carlos.