glibc CTI migration - outstanding concerns

[Andrew Pinski]

On Tue, Sep 29, 2026 at 4:39 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> Let me see if I can start over with a fresh thread because the earlier
> one is going around in circles.  I'm making it bullet points in the hope
> that it's easy to speak to specific points, and I've split them into
> sections in the hope of making it more readable.
>
> The background:
> ===============
>
> * Hardware infrastructure used for hosting critical services (git and
> email being the ones in question here, but more generally also bugzilla,
> wiki, website, etc.) has not scaled for a while, it's been 2 machines (3
> now) and pretty much everything from bugzilla and git to the website run
> on these.
>
> * The infrastructure is a performance bottleneck that has bled between
> services (bugzilla slowing down git, etc.) in the past and currently is
> running only because it blocks masses of users (because of AI scraper
> bots) who have to contend with 429 rejections.  Regular users don't see
> it much because IP blocks get safelisted using various heuristics, but
> the "scaling" still relies largely on trying to discriminate between
> users and denying services.
>
> * Everything running on one server also had the security risk of one
> service breach propagating to another service. There was one instance of
> this (I don't remember the details but Joseph Myers does I believe)
> where we just got lucky that a compromise was not leveraged much
> further.  Overseers have, over the last few years started containerizing
> the services, but it's still all on one machine and is one container
> escape exploit away.
>
> * Administration of these systems relies on volunteers and is
> essentially a spare time activity.  Volunteers have dwindled over the years.
>
> * The infrastructure for the critical services have a single sponsor,
> i.e. Red Hat and hardware upgrades rely on Red Hat's budget/desire.
> There have been buildbot workers, CI runners, etc. from other
> organizations like OSUOSL, Linaro, etc. but they don't feed into
> critical infrastructure.
>
> The Proposal:
> =============
>
> * Some contributors and maintainers of the GNU toolchain projects looked
> for alternative sources for infrastructure maintenance and funding to
> mitigate the risks identified above.
>
> * We agreed upon the Linux Foundation being the most suitable for this
> due to their extensive experience in hosting and scaling the Linux
> kernel infrastructure.
>
> * The first proposal in 2022 was to have LF IT take over maintenance of
> sourceware (which then was the machines, not the project that it is
> today) but overseers refused to join or even relinquish control oveer
> the infrastructure and decided to form the sourceware PLC under SFC.

You missed the big event that happened in 2022.  Which does effect the
timeline a lot.
You missed the event that happened at the 2022 cauldron.  I know you
said you "it was taken care of" afterwards but that does not mean it
didn't happen.
Also you missed that overseers offered Carlos a spot (which overrides
their own rules of having only one represented per company).
So your retelling of the story is very baised towards CTI/TAC/LF.

>
> * glibc was identified as the first project to move since it is small
> enough and the community is usually quite amenable to trying new things.
>
> * The proposal has since been scoped down to just critical services
> since that mitigates most of the risk we see on the infrastructure,
> maintenance and security fronts.
>
> * The reduced proposal also works well fiscally for project
> infrastructure since it now taps into two sources of funding, one
> through LF and the other through SFC.
>
> * The reduced proposal also gives space to experiment with new workflows
> and services at sourceware (the forge for example) allowing the
> community to try different things.
>
> Governance:
> ===========
>
> * The structure of the project is essentially a tripartite system
> involving the Linux Foundation, the CTI TAC (deliberately separate from
> the GNU toolchain projects to maintain FSF control over the latter) and
> sponsor corporations.
>
> * The Linux Foundation provides a forum for the CTI TAC to solicit
> funding from sponsor corporations for their project needs.
>
> * The fact that LF IT is the recipient of the proposed funding for
> infrastructure is a CTI decision, i.e. the CTI TAC believes that this is
> the way forward for critical infrastructure.
>
> * The project itself has representatives from the sponsor corporations
> in the Governing Body (GB), which has two roles: (1) approve funding of
> proposals put forward by the TAC and (2) approving new TAC members
> proposed by the present TAC.
>
> * The GB cannot unilaterally add members to the TAC and cannot come up
> with proposals on behalf of the TAC.  They can only vote yes/no to
> proposals presented by the TAC.
>
> Outstanding concerns:
> =====================
>
> * There's an impression that the GB directly controls the functioning of
> the TAC.  This is not true; the GB only controls funding and not the
> technical direction, which is solely controlled by the TAC.
>
>    - Would adjustment of wording in the charter[1] address this concern?
>    - What would that adjustment look like?
>    - Is the above clarification sufficient or are there further concerns?
>    - If there are concerns, how could they be addressed?
>
> * The second concern over governance is that the TAC could get
> progressively stuffed with GB sympathizers and eventually be influenced
> by GB interests and not the project.
>
>    - Would a formally defined process to propose members from the GNU
> toolchain community to the TAC resolve this?
>    - Would wording adjustment to the charter clarifying that only the
> TAC is allowed to modify its composition help?
>
> * Critical vs non-critical services: there's are a couple of suggestions
> to move non-critical services over instead of the critical ones,
> reasoning that we could then evaluate LF IT services with a lower risk.
> There's a difference in opinion over what constitutes a risk, with some
> thinking that the current situation is risky while others arguing that
> the status quo is better than the unknown.
>
>    - Would further granular staging of the migration help?  The LF IT
> migration plan already has a ro vs rw split to manage traffic.  Would it
> help to migrate the ro bits first, i.e. make that the canonical way for
> users to get glibc sources from git and restrict sourceware git to just
> ssh?  I don't know how easy/hard it would be for LF IT to set this up,
> but no reason why we cannot riff on it.
>
>    - Is the canonical ro repository hosted on LF IT infrastructure OK
> even before we agree on the governance questions above or does anyone
> see risks to that?
>
> * Trademark related questions
>
>    - Are there any further trademark related concerns since renaming the
> project to CTI?  I've not heard Zoey state this, only Mark conjecturing.
>    - What specific changes to the charter would help alleviate these
> concerns?
>
> I've not listed consensus/voting as one of the concerns here because
> that subthread is becoming an ugly finger pointing exercise that I'm
> sure is making others as angry and gaslit as I'm feeling.  I hope that
> some of the questions and suggestions I've raised above will drive the
> conversation forward.
>
> Sid
>
> [1] https://cti.coretoolchain.dev/gov/charter.html