CTI - Making a decision for glibc.

[Andrew Pinski]

On Thu, Jan 29, 2026 at 3:13 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> 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.

Who is "we"? It is not obvious if that is CTI or representation of
developers/maintains/reviews or what?

>
> 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.

So there was no support path in place in the first place how can move
happen without that?

>
> 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.

Give an example (which was not an emergency change that was needed here)?
The shutting down https git access was an emergancy change needed for
the night and was wrote to the lists telling people it happened and
why.

>
> 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.

This is lie. And you know it is lie. disabling https git access was an
emergancy change. It was not something done lightly either.

>
> 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).

So how do is the team voted upon or appointed? But still I think this
is more layers for what end?

>
> 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.

Which we is this we here?

>
> (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.

Who is we here? CTI TAC or some other group?
CTI TAC is not voted upon by developers so it does not represent
developers of the project.

>
> (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.

I think I am talking about more than gcc but glibc should really think
about doing the forge instead for new developers and such.

>
> --
> Cheers,
> Carlos.
>
> [1] https://codeberg.org/Codeberg-Infrastructure/meta
>