glibc CTI migration - outstanding concerns

[Siddhesh Poyarekar]

On 2026-09-30 10:24, Mark Wielaard wrote:
> 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.

We're not, because the core issue here is that you keep responding to 
this with "lets do this in sourceware" and "lets have the CTI fund 
sourceware" when those are not goals of the CTI anymore.

I restarted this with the idea to make that distinction: the CTI 
proposal does not involve sourceware because sourceware decided to go 
its own way with SFC.  Maybe the sourceware PLC could make a proposal to 
the CTI TAC for funding, outlining how the fund would be directed and we 
could take that to the CTI?  For that though, the CTI needs to actually 
go live first, which is what I'm trying to do now.  We've been sitting 
in the "almost there" position for so long that nobody involved in this 
is sure which way this will go.

What I would request of you Mark is: take off your sourceware PLC hat 
and keep only your glibc contributor hat on and look at the CTI proposal 
to suggest what could change that would lead you to withdraw your 
objection to the proposal.

>>>     - 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.
The way I see this working is that sourceware git is ssh-only (maybe 
with http forwarding to help with migration?) and the glibc website 
updates its instructions[1] to get sources from cortoolchain.dev.

Sid

[1] https://sourceware.org/glibc/sources.html