glibc CTI migration - outstanding concerns

[Mark Wielaard]

Hi,

On Tue, Sep 29, 2026 at 09:10:45PM -0700, Andrew Pinski wrote:
> 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.

I actually thought we were making progress with a possible plan to
move forward:
https://inbox.sourceware.org/20260929193713.GM3136@gnu.wildebeest.org/
Which I think also addresses some of your concerns stated in this
summary, which seems based on some outdated information.

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

To be fair to Sid, he wasn't present when the physical attack and all
the yelling and shouting happened. Also as far as I know this person
isn't involved anymore in this effort.

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

Setting up Sourceware as a SFC member project was meant to best match
the kernel.org structure, which is also a public benefit corporation
funded through some of the LF member companies. Which we believed was
what Carlos suggested us we do when he first mentioned getting funding
through the LF, so the community could hold assets and funds.

As far as I know we have always been open to help from the LF/IT with
maintenance and/or funding through LF/CTI. We just haven't found the
right way yet. Which I guess is this discussion.

That SFC structure also means that the new servers we acquired last
year are actually owned by and paid through community donations and/or
donated through entities other than Red Hat (Red Hat does still host
and maintains them together with OSUOSL).

And this quarter we added three new corporate sponsors. Combined with
the individual donations this quarter that covers 2/3rd of our
2026/2027 budget to hire some paid staff/consultants:
https://inbox.sourceware.org/6f6b79ecac58c7d2fa1c65cb6f65ce418882321b.camel@klomp.org/
And we just received another big donation that covers the other 1/3rd
of that budget.

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

Having a read-only mirror of git repositories is of course welcome.
Not sure I would classify that as a migration or canonical.  But on
itself it would certainly be useful.  We could setup grokmirror on
sourceware to make this easier.

Cheers,

Mark