CTI - Making a decision for glibc.

[Carlos O'Donell]

On 1/28/26 7:11 PM, Andrew Pinski wrote:
> On Wed, Jan 28, 2026 at 4:00 PM Carlos O'Donell <carlos@redhat.com>
> wrote: There is something which you missed from my previous email
> which ties into (1) and (2). Here. What is the support path? From
> say someone in the community noticing something is not working to LF
> IT? This is just as important as figuring out if moving and using LF
> IT (or anyone else really). Right now there is both a form path via
> bugzilla infstructure issues and an inform one via email and IRC.

tl;dr Today the CTI, on behalf of glibc and the GNU Toolchain,
emails the LF IT ticket queue e.g. please make a new BBB room with
the following people as room admin.

Just like we evolved this with Sourceware, we get to evolve this with
CTI into something that supports glibc and the GNU Toolchain and works
for LF IT.

There are 3 points I think we should consider in this area.

(1) Developer led.

Project developers should own and lead the process.

We will own several parts of the process of maintaining our
infrastructure e.g. gitolite keyring repo, mailing list moderation.

We should be opinionated about what we want, the services
are for us and serve us to improve the GNU Toolchain.

We should identify who wants to step into that role and empower
them to write up what a reasonable support path should look like.

There may be infrastructure issues that just turn out to be
help requests, and as a community we should help with those.

(2) Data driven.

If we have an infrastructure issue, and I'm opinionated here,
we should *always* file an infrastructure bug.

Without those issues we have no way to look back on the year, and
reflect on the problems we might have had and how we can improve
things (also not surprisingly a part of the SSDLC).

The data here should also include:

  * talking to other shared-infra users for consensus

  * approval for the change.

  * what was done to workaround or correct the issue so we can
    review what did and didn't work.

(3) With the option to escalate.

We always need an escalation path in case something serious goes
wrong and we need it escalated.

We need to collaborate with LF IT to determine what this would look
like and under what conditions we should escalate (see (1)) and
who can escalate.

Today there isn't a documented escalation path in the SOW, but it
can and should be discussed.

Today CTI sends an email.

See (1) about this needing to be developer led.

---

Joseph Myers has raised this issue a few times in previous threads,
and I want to raise it again.

On occasion we sometimes jump to implement changes in our
infrastructure because someone said something on IRC, or emailed
the right person, but these changes sometimes needed broader
consideration for the shared teams using that infrastructure.

Such changes are not always recorded anywhere so we can't review
them or decide if they were the wrong thing to do in the long run.
Including auditing them for security impact e.g. disabling https.

I think a coordinated approach with a team of developers being
our IT liasons would be very valuable, in fact I think a rotating
team lead could be very effective (like we are doing with the glibc
security team).

I suggest attending the Office Hours for CTI on Friday, or a
subsequent office hours. We will rotate them around timezones.

I've setup #cti-help on OFTC for asynchronous discussions.

> This is really important when stuff comes up like the recent AI bot
> scrappers attacks. And it is also important when there has been in
> the past with locks needing to be removed (e.g. git locks up in some
> cases due to large number of commits due to the post-recievce
> hooks). Does it need to go to CTI (or a representative) first or is
> there a direct line for all community members? That is the bigger
> question and part of the problem I see with the out sourceing of IT
> support here. Also is there future cost of including new
> infrastrcture needs in? Like say a new bugzilla instance or a forge
> that has been already planned out.

This last paragraph has a lot of questions that I am splitting here.

(a) Option to escalate I covered in (3).

(b) New infrastructure needs should be discussed, and the GNU Toolchain
     working with the CTI TAC needs to put together a proposal that we
     can evaluate for cost, now and over time.

(c) If we have new infrastructure needs beyond what we have in our
     SOW, then we need to cost them out, and determine if we can pay
     them.

(d) Forge hosting should be evaluated as new infrastructure with
     an eye towards figuring out the current cost and long-term costs,
     along with security and maintenance. This is absolutely something
     we can do, but was not part of the original SOW as it is still
     an evolving discussion. Right now for glibc there is no plan to
     use a forge, and any workflow changes have to come from the
     developers. I expect here that you're talking about gcc.

-- 
Cheers,
Carlos.

[1] https://codeberg.org/Codeberg-Infrastructure/meta