Meeting Minutes - Office Hours for CTI - 2026-06-05

[Carlos O'Donell]

On 6/5/26 3:04 PM, Andrew Pinski wrote:
> On Fri, Jun 5, 2026 at 8:42 AM Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> Agenda:
>>    * Discussed where to put the glibc services transition plan.
>>    * Discussed adding it to the glibc wiki.
>>    * Started document here: https://sourceware.org/glibc/wiki/service-transition-plan
>>    * Next steps are to get the community involved in the discussions.
> 
> I am not sure August 20th is duable.

Thanks for the feedback. I've been updating the transition plan as we go
working on it.

> Where is the plans for bugzilla integration with git? And changing the
> git hooks? I have NOT seen any plan on the git hooks yet.

Please have a look again at the wiki page today, it includes the 12 AdaCore
sections in the config file and what we would do with them.

The git to bugzilla is planned to be a webhook that delegates the push
to a distinct system that we're talking to LF IT about.

> Where is the plans for linking to the old mail archives? Are there
> plans on hosting the full mail archives on CTI services? I have not
> seen any mention of either of these issues anywhere.

(1) Old mail archives.

The per-service transition plan includes a clone of the public-inbox
archive which is all the email from the project. Which includes
an archive of the current active lists.

Links to the old mailing list URLs would go to the sourcweare archives.

(2) Archive non-active mailing lists too.

It was not on the list to archive things like libc-hacker though,
but they can be e.g. https://inbox.sourceware.org/libc-hacker/ exists
and can therefore be cloned and mirrored such that anyone can clone
and mirror the CTI mailing lists too.

Is this what you mean?

(3) Retain URL archives for non-public-inbox archives.

For non-public-inbox the request would be for Sourceware to keep the
URLs as archive for projects that had been previously hosted there,
and I call out that request in the plan.

> Why is the forge not an option? Just because CTI says so or is it
> because the glibc community didn't know that was an option?

Transitioning to the forge is a longer conversation.

With my GNU Project maintainer hat on I would like to see the glibc
community experiment with the workflow on the Sourceware Forge.

I think using Sourceware Forge to experiment and develop a workflow
without production constraints is a perfectly acceptable next step
for the community evaluation.

When it gets to deploying a Forge in production I think I'd ask all
the same questions I'm asking for CTI. How do we maintain it in a
sustainable way? Looking at what CodeBerg does on the backend raises
questions for me about what is required for robustness.

> The transition plan is weak and has too many TBDs to even think about
> August 20th as a cut over date.

With the updated plan I think we can achieve that date, but I'll send
out an email shortly about this. I'd like to hear more about the timing
between our post-release activities and a cut-over. Like if we think
September is better given the post-release fixes.

> What is the rush here; is it because the money needs to be spent? Can
> we do this correctly and that includes doing a forge for glibc? Why
> not put some of that money towards improving a forge? Instead of
> hosting?

Why drag out improving the existing critical infrastructure for the
project?

I think we can do a Forge, but that requires other work to happen.

I've commented a few times that I'd like to see Fedora's transition
go first and see what they shake out of the process:
https://forge.fedoraproject.org/

I expect Fedora to drive specific improvements to Forgejo that would
benefit the GNU Toolchain.

Likewise glibc developers would have to experiment more with the Forge,
and the Sourceware Forge is one option?

> What features does CTI services provides that is not already handled
> by sourceware? Why can't money go towards improving sourceware? Or
> even stuff like the forge. Why spend extra money on an extra host?
Today CTI will provide:
  * Global git mirror network
  * Robust email
  * Isolated hardened services in support of git-hooks/email-integration.
  * Paid IT staff
  * 2FA: Support developers using hardware backed ssh keys [1]

And we will continue the migration for other services after the core
services.

I think the money is better spent paying an IT team that has
operational experience deploying the services we use today at scale.
That is why CTI is using LF IT for services.

If we have specific Forge request I think they should absolutely go
to the CTI TAC for review and we can talk about them: [2]
cti-tac@lists.linuxfoundation.org

Extra money will have to be spent either way to enable a Forge in
production with sufficient isolation, backup, and operational
capacity. See CodeBerg's current design
https://codeberg.org/Codeberg-Infrastructure/

Paying for a production-grade forge is going to be a serious next
step if we take it, but I consider that step easier, not harder,
once we have CTI rolling given the current funding.

-- 
Cheers,
Carlos.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=33894
[2] https://subspace.kernel.org/lists.linuxfoundation.org.html