CTI - Making a decision for glibc.

Thu Jan 29 00:11:01 GMT 2026

On Wed, Jan 28, 2026 at 4:00 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 1/28/26 5:26 PM, Andrew Pinski wrote:
> > On Wed, Jan 28, 2026 at 2:13 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> >>
> >> On 2026-01-28 16:45, Zack Weinberg wrote:
> >>> 1. It's my impression that there are a small number of people (Carlos
> >>>      O'Donell, David Edelsohn, Joseph Myers, and possibly *no one else*)
> >>>      who feel strongly that glibc should move off of sourceware.org, and
> >>>      *everyone else* with a stake in the matter is somewhere on a spectrum
> >>>      between neutral and a strong belief that glibc *shouldn't* move, or
> >>>      at least, should not move to infrastructure hosted by the Linux
> >>>      Foundation.
> >>
> >> If you're naming names it's Carlos O'Donell, David Edelsohn, Joseph
> >> Myers, Siddhesh Poyarekar, Florian Weimer, Maxim Kuvyrkov, Jeff Law and
> >> Andreas Huettel who have vocally supported the move in this thread,
> >> while many others (who I hope will chime in too) who contribute on a day
> >> to day basis, have expressed support offline in the past.  Your base
> >> characterization of the situation is flawed I'm afraid.
> >
> > Let me speak up on why sometimes the characterization of the
> > situtation gets flawed here. The issue is hosting on sourceware vs
> > LF IT doing the hosting is being conflated with the security side of
> > things. And the only side that is doing that conflated is the side
> > that has been very vocal on moving to LT IT.
>
> A proposal should consider multiple factors.
>
> (1) Security.
>
> We could solve security with any FOSS-based solution so long as those
> solutions meet our SSDLC.
>
> In fact in the SSDLC for glibc I note that we'll continue to use
> the GNU Project services for uploading signed binary artifacts
> because it is a requirement of the GNU Project and it is a well
> designed robust, isolated, and simple system.
>
> It isn't the best we can do, but it's good enough to recommend and
> changing that process requires more conversations with the GNU Project
> and project developers. CTI is not a governance or workflow change.
>
> Solving security issues is still a *timely* problem as downstreams
> continue to ask questions about robustness and availability along with
> security. We want the ecosystem to trust FOSS-based solutions, and
> to use them first.
>
> (2) Sponsorship.
>
> We are looking for a straight forward mechanism to fund infrastructure
> by reaching out to the largest companies that benefit directly downstream
> from GNU Toolchain development.
>
> Those sponsors including AMD, arm, IBM, Intel, NVIDIA, Oracle, Red Hat,
> Qualcomm, are all part of the Linux Foundation (a chamber of commerce),
> and so no matter the IT team we'd still likely create an Associated
> Directed Fund at the LF to gather sponsorship.
>
> I am one of 3 trustees in the GNU Toolchain Fund at the FSF, but there
> is not enough money there to fund this type of initiative in the long
> run. We need larger corporate sponsors.
>
> David Edelsohn, Joel Brobekcer, and I know how hard it is to get real
> money on the table, and I'm empathetic with Sourceware's work with the
> SFC to raise funds.
>
> Lastly, we could attempt to route more funding to either the FSF or
> the SFC, but both are US charities. This means that the donations are
> arms length, which means we can't say "this money shall be used for
> X" and instead the charity decides what to do with the funds against
> their charitable mission. Now, the distinction is germane because
> while the FSF has been amazing at helping us run the GNU Toolchain
> Fund, what is harder is convincing other large sponsors, that might
> not have the same relationship, to give a fully charitable donation.
> In the context of an LF ADF, we have a charter, and sponsors can be
> fiscally accountable for the spend. The distinction is real and some
> sponsors prefer it because they can say "We spent directly on X to
> improve security." rather than "We donated to a charity."
>
> (3) Experience.
>
> Whoever implements the solution should have experience with FOSS-based
> solutions.
>
> LLVM Foundation, and I've talked to Tom Stellard about them, is using
> Github, and that doesn't match our community values.
>
> Rust Foundation, and I've talked to Josh Stone about their development
> process, is using Github, and that doesn't match our community values.
>
> Mozilla Foundation is struggling and also uses Github for all of their
> official repositories as far as I know, and that doesn't match our
> community values.
>
> If you look across the landscape, many projects turn towards the lowest
> cost and simplest path of using Github, or Gitlab, and that isn't a
> direction aligned with our values.
>
> FOSS using IT teams today include LF IT, Sourceware and probably the
> Fedora Community Infrastructure team, along with downstream distros
> and many more self-hosted companies.
>
> The teams with the longest established records are probably Sourceware,
> FSF IT/GNU Project, and LF IT.
>
> I have excluded the distribution teams because I expect this would put
> a disproportionate load on their volunteers and I expect the larger
> distributions should support the toolchain financially (see (2)).
>
> > So let's step back both sides on this and talk about one thing and
> > only one thing. That is the hosting of glibc project. Security
> > issues do have dependency on which side is chosen to some extent.
> > BUT from the contract of CTI and LF IT before it was still most of
> > the heavy lifting was going to be the community rather than the LF
> > IT. Which brings up another point why LF IT why not LLVM foundation
> > IT (if it exists any more)? Or say Rust foundation or Mozilla
> > foundation IT? It was seemed like there was only one choice and ever
> > once one choice. Why not use FSF IT instead?
>
> The LF IT contract had two parts:
>
>   (1) Moving the infrastructure from Sourceware to LF IT.
>
>   (2) Operation of the services.
>
> The community has to be involved in (1) to make sure it goes smoothly.
>
> When it comes to (2), we aren't doing any heavy lifting, and we're back
> to operation as normal, but with paid IT, the benefits as discussed,
> and our normal workflows.

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

>
> You ask "Why LF IT?" see the combination of (1)(2)(3).
>
> My position is that for the level of infrastructure spending we need
> it's hard to get fully charitable donations, so in combination it is
> simpler to use a chamber of commerce structure, followed by a team
> already at the chamber of commerce that meets our requirements.
>
> > Also I am still wondering about this statement what changed after it:
> > As of 2025-08-11 moving to new infrastructure is on hold as we discuss
> > the core reasons for the migration.
>
> I have finished writing SSDLC's with requirements for glibc:
> https://inbox.sourceware.org/libc-alpha/4e9f65ea-a1bf-4d69-9dd5-63aa301f0b42@redhat.com/
>
> We have started using the SSDLC, for example to raise issue with
> Sourceware's current operations:
> https://inbox.sourceware.org/overseers/d894fead-dff1-46c5-9b1f-8a5dade9b986@redhat.com/
>
> I also wrote a comparison of Sourceware's checklist to the recommendations for glibc:
> https://sourceware.org/glibc/wiki/SSDLC/Policy/Sourceware
>
> Again, this only considers (1), not (2) or (3).
>
> > yes I saw this:
> > As of 2025-08-19 an evaluation of glibc moving from git to gitolite is
> > in progress.
> > But that can be done with any hosting including sourceware.
>
> Which doesn't consider the sustainability of the solution, or the robustness
> or availability?
>
> Frank said Sourceware has $0 for operations and capital spending:
> https://inbox.sourceware.org/overseers/20251029171555.GB21228@redhat.com/
>
> See (2).
>
> > Which also gives way to this from
> > https://lore.kernel.org/cti-tac/3b1aaa90-9b46-4ce3-9209-4b9c358107d9@redhat.com/:
> >    * Carlos to post to the glibc mailing list to raise infrastructure move again.
> >
> >  From https://lore.kernel.org/cti-tac/4c7f3274-1c2d-4ae6-935a-5ceb656d71c4@redhat.com/
> >    * Disucssed 5 whys and why we're still on existing infrastructure
> > versus a transition.
> >
> > So what is the 5 whys?
> The "5 Whys" is a technique to arrive at the root cause of something.
>
> Why are we still using Sourceware infrastructure?
> 1. Because we still had some questions to answer around defining an SDLC.
> Why?
> 2. To go through the steps of evaluating more of the project life-cycle and requirements.
> Why?
> 3. To determine if there are other requirements we didn't consider.
> Why?
> 4. The requirements might change our choice of IT team or sponsors.
> Why?
> 5. Because we want to make lasting durable choice.
>
> --
> Cheers,
> Carlos.
>