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

[Andrew Pinski]

On Tue, Jun 23, 2026 at 4:06 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> 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.

So looking into the updated plan, There are no estimates on the days
each part of `Git Service Transition` will take.
The `Per-service Transition Plan` has no estimates either.




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

Because moving hosting service does not improve infrastructure.

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

And I comment each time that glibc is small enough that it should be
on the forfront there instead of waiting.

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

Why not the GNU toolchain drive the specific improvements to Forgejo
instead? That was my point to begin with.

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

Why has this not started yet? The forge experiment has been going on
for over a year now for GCC. In fact it is to the point where GCC is
getting patches only via the forge for some newcomers.



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

Can you expand on robust email? Because as far as I understand the
same issues are existing and will exist due to the nature of email in
general. This is another reason why going to a forge pushes out the
need for this.

>   * Isolated hardened services in support of git-hooks/email-integration.

Who is doing the work there because it is not part of your plan and
there is nothing stopping being done on the current hosting site.

>   * Paid IT staff

Is this a benifit or you just think it is. I asked before about
escalation paths and such for support here. And all I got back it was
a vague answer saying "we".

>   * 2FA: Support developers using hardware backed ssh keys [1]

This is just a software issue due to rhel8.

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

This is where I (and many others) disagree. Money spent on
developement of the forge is a long term solution; while spending
money on changing hosting is a short term solution for a huge pain
(and some what a community mistrust going on).

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

So money for hosting only? Sounds like a solution for short term
issues rather than thinking very very long term.

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

"Production grade" I like how this is turned into a buzz word email.
Because the current forge is production grade because it is in
production.

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