Meeting Minutes - Office Hours for CTI - 2026-09-18

Meeting Minutes - Office Hours for CTI - 2026-09-18

[Carlos O'Donell via Gdb]

CTI: https://cti.coretoolchain.dev/

The CTI project holds Office Hours every Friday, these are the minutes for this Friday's meeting.

The CTI project in collaboration with glibc is working on: https://cti.coretoolchain.dev/projects/glibc.html

Posting across the project mailing lists since some developers had questions and are only subscribed on some lists.

​Agenda:
  * Community items that need review.
  * 1. What does the ouput of vcs to email look like? Post to libc-alpha for review.
   * What does the output of git-mailbomb-cron look like.
    * Asked LF IT on #cti-help for examples of output.
   * 2. What does the output of bug text to bugzilla look like? Post to libc-alpha for review.
    * Asked LF IT on #cti-help for examples of output.
  * Come up with exact DNS names for services that can be split and moved.
   * Support using DNS to route services in the future and for isolation.
   * Even though isolation can be achieved at the proxy side after DNS, the splitting is easier with DNS.
  * Discuss on libc-alpha finalizing git URLs
   * git.glibc.coretoolchain.dev/glibc (RO mirror)
   * gitolite.glibc.coretoolchain.dev/glibc (RW for developers)
   * gitolite.glibc.coretoolchain.dev/glibc-keyring (RW for admins)
  * Discuss on libc-alpha finalize mailing list names:
   * Place mailing list services under lists.glibc.coretoolchain.dev
   * glibc-announce@lists.glibc.coretoolchain.dev
   * glibc-devel@lists.glibc.coretoolchain.dev
   * glibc-stable@lists.glibc.coretoolchain.dev
   * glibc-testresults@lists.glibc.coretoolchain.dev
   * glibc-help@glibc.lists.glibc.coretoolchain.dev
   * glibc-vcs@lists.glibc.coretoolchain.dev
  * ACTION: Carlos to email the mailing list with proposals for discussion.

-- 
Cheers,
Carlos.

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Andrea Pinski via Gdb]

On Mon, Sep 21, 2026 at 9:34 AM Carlos O'Donell via Gcc <gcc@gcc.gnu.org> wrote:
>
> CTI: https://cti.coretoolchain.dev/
>
> The CTI project holds Office Hours every Friday, these are the minutes for this Friday's meeting.
>
> The CTI project in collaboration with glibc is working on: https://cti.coretoolchain.dev/projects/glibc.html
>
> Posting across the project mailing lists since some developers had questions and are only subscribed on some lists.

This assumes that there is consensus on moving forward with any
proposal.  And second, there is not enough information in these
meeting notes.
They don't contain the attendance which is important to understand why
there is not much discussion around the issues already raised.
The notes don't contain the rationale for the choices on hand; for an example:

>
> Agenda:
>   * Community items that need review.
>   * 1. What does the ouput of vcs to email look like? Post to libc-alpha for review.
>    * What does the output of git-mailbomb-cron look like.
>     * Asked LF IT on #cti-help for examples of output.
>    * 2. What does the output of bug text to bugzilla look like? Post to libc-alpha for review.
>     * Asked LF IT on #cti-help for examples of output.
>   * Come up with exact DNS names for services that can be split and moved.
>    * Support using DNS to route services in the future and for isolation.
>    * Even though isolation can be achieved at the proxy side after DNS, the splitting is easier with DNS.
>   * Discuss on libc-alpha finalizing git URLs
>    * git.glibc.coretoolchain.dev/glibc (RO mirror)
>    * gitolite.glibc.coretoolchain.dev/glibc (RW for developers)
>    * gitolite.glibc.coretoolchain.dev/glibc-keyring (RW for admins)

What is the rationale for having 3 different URLs? What is the
rationale for using `coretoolchain.dev` rather than something more
specific named with gnu?
Why have a glibc subdomain?  Etc.

>   * Discuss on libc-alpha finalize mailing list names:
>    * Place mailing list services under lists.glibc.coretoolchain.dev
>    * glibc-announce@lists.glibc.coretoolchain.dev
>    * glibc-devel@lists.glibc.coretoolchain.dev
>    * glibc-stable@lists.glibc.coretoolchain.dev
>    * glibc-testresults@lists.glibc.coretoolchain.dev
>    * glibc-help@glibc.lists.glibc.coretoolchain.dev
>    * glibc-vcs@lists.glibc.coretoolchain.dev

Especially here about why not just have lists.coretoolchain.dev rather
than have a glibc subdomain.  Plus isn't glibc on the mailing list
name and the domain redundant?
There is no rationale there at all; even the previous meetings notes
don't mention why.  Rather just the final choices.

This is a communication failure and a trust issue here.

>   * ACTION: Carlos to email the mailing list with proposals for discussion.
>
> --
> Cheers,
> Carlos.
>

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[DJ Delorie via Gdb]

On Mon, Sep 21, 2026 at 1:12 PM Andrea Pinski via Gdb
<gdb@sourceware.org> wrote:
> >   * Discuss on libc-alpha finalizing git URLs
> >    * git.glibc.coretoolchain.dev/glibc (RO mirror)
> >    * gitolite.glibc.coretoolchain.dev/glibc (RW for developers)
> >    * gitolite.glibc.coretoolchain.dev/glibc-keyring (RW for admins)
>
> What is the rationale for having 3 different URLs?

The first is a general public-access git tree like everyone else uses.

The second is a way to integrate remote git work (i.e. on your pc)
with the master repository.  It replaces login-style SSH as a way to
"git push" with a key-based style.  I've used it before and it's much
easier to use and manage than raw git repos with SSH logins, and does
not require that contributors have a login account on the git host.

The third is the "management interface" for gitolite.

The alternative to gitolite is to use a fork-and-pullrequest model
(like gitlab, requires a web interface) or continue using login
accounts.

Having the developer repo separate from the public repo helps isolate
the developers from the AI scraperbots, as the public one could be
redirected through a CDN.

> What is the rationale for using `coretoolchain.dev` rather than
> something more specific named with gnu?

Meh?  Are ALL the core toolchain bits part of the GNU project?  Will
they always be?  Do we want to be GNU snobs? ;-)

> Why have a glibc subdomain?

To make room for gcc.*, binutils*, gdb.*, etc.

> >   * Discuss on libc-alpha finalize mailing list names:
> >    * Place mailing list services under lists.glibc.coretoolchain.dev
> >    * glibc-announce@lists.glibc.coretoolchain.dev
> >    * glibc-devel@lists.glibc.coretoolchain.dev
> >    * glibc-stable@lists.glibc.coretoolchain.dev
> >    * glibc-testresults@lists.glibc.coretoolchain.dev
> >    * glibc-help@glibc.lists.glibc.coretoolchain.dev
> >    * glibc-vcs@lists.glibc.coretoolchain.dev
>
> Especially here about why not just have lists.coretoolchain.dev rather
> than have a glibc subdomain.  Plus isn't glibc on the mailing list
> name and the domain redundant?

This assumes that all projects want to have their project name in
their mailing list names.  For example, gcc might want
"patches@lists.gcc.*" or "patches@gcc.*"

I would not be opposed to renaming our mailing lists to be
"foo@glibc.*" instead of "glibc-foo@.*" if we're moving them *at all*.

I don't think we need the "lists." part in the mailing list name - MX
records can redirect glibc.* to lists.glibc.* unless there are
technical reasons to not send local non-list mail (there shouldn't be
any IMHO) through the list server host.

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Siddhesh Poyarekar]

On 2026-09-21 13:58, DJ Delorie wrote:
>> Why have a glibc subdomain?
> 
> To make room for gcc.*, binutils*, gdb.*, etc.
> 
>>>    * Discuss on libc-alpha finalize mailing list names:
>>>     * Place mailing list services under lists.glibc.coretoolchain.dev
>>>     * glibc-announce@lists.glibc.coretoolchain.dev
>>>     * glibc-devel@lists.glibc.coretoolchain.dev
>>>     * glibc-stable@lists.glibc.coretoolchain.dev
>>>     * glibc-testresults@lists.glibc.coretoolchain.dev
>>>     * glibc-help@glibc.lists.glibc.coretoolchain.dev
>>>     * glibc-vcs@lists.glibc.coretoolchain.dev
>>
>> Especially here about why not just have lists.coretoolchain.dev rather
>> than have a glibc subdomain.  Plus isn't glibc on the mailing list
>> name and the domain redundant?
> 
> This assumes that all projects want to have their project name in
> their mailing list names.  For example, gcc might want
> "patches@lists.gcc.*" or "patches@gcc.*"
> 
> I would not be opposed to renaming our mailing lists to be
> "foo@glibc.*" instead of "glibc-foo@.*" if we're moving them *at all*.
> 
> I don't think we need the "lists." part in the mailing list name - MX
> records can redirect glibc.* to lists.glibc.* unless there are
> technical reasons to not send local non-list mail (there shouldn't be
> any IMHO) through the list server host.

The base reasoning here is that we'd like the infrastructure for 
projects to be independent and easy to move independently.

Sid

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Mark Wielaard]

Hi,

On Mon, Sep 21, 2026 at 09:55:47AM -0700, Andrea Pinski via Gdb wrote:
> On Mon, Sep 21, 2026 at 9:34 AM Carlos O'Donell via Gcc <gcc@gcc.gnu.org> wrote:
> > Posting across the project mailing lists since some developers had
> > questions and are only subscribed on some lists.
> 
> This assumes that there is consensus on moving forward with any
> proposal.  And second, there is not enough information in these
> meeting notes.
> [...]
> >   * Discuss on libc-alpha finalizing git URLs
> >    * git.glibc.coretoolchain.dev/glibc (RO mirror)
> >    * gitolite.glibc.coretoolchain.dev/glibc (RW for developers)
> >    * gitolite.glibc.coretoolchain.dev/glibc-keyring (RW for admins)
> 
> What is the rationale for having 3 different URLs? What is the
> rationale for using `coretoolchain.dev` rather than something more
> specific named with gnu?
> Why have a glibc subdomain?  Etc.

If you want and have a good rational then Sourceware could of course
provide (sub)domains like glibc.sourceware.org or
gnu.toolchain.dev/glibc or (in cooperation with the fsf-tech team)
glibc.gnu.org, etc. backed by different VMs or services.

> [...]
> There is no rationale there at all; even the previous meetings notes
> don't mention why.  Rather just the final choices.
> 
> This is a communication failure and a trust issue here.
> 
> >   * ACTION: Carlos to email the mailing list with proposals for discussion.

Best action item would be to first seek concensus on moving forward
with any of these proposals. Otherwise you risk spending time on
things nobody will use or worse create a fork and split the community:
https://inbox.sourceware.org/3fb85049-8d6a-4f83-a0a3-770cc385e6af@app.fastmail.com
Like Zoë said we could achieve much more by working together:
https://inbox.sourceware.org/7021a9fb-2476-463c-8eab-a4e254d93df2@fsf.org
And there have been many constructive suggestions how we could do that.

Cheers,

Mark

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Joseph Myers via Gdb]

On Mon, 21 Sep 2026, Andrea Pinski wrote:

> >   * Discuss on libc-alpha finalize mailing list names:
> >    * Place mailing list services under lists.glibc.coretoolchain.dev
> >    * glibc-announce@lists.glibc.coretoolchain.dev
> >    * glibc-devel@lists.glibc.coretoolchain.dev
> >    * glibc-stable@lists.glibc.coretoolchain.dev
> >    * glibc-testresults@lists.glibc.coretoolchain.dev
> >    * glibc-help@glibc.lists.glibc.coretoolchain.dev
> >    * glibc-vcs@lists.glibc.coretoolchain.dev
> 
> Especially here about why not just have lists.coretoolchain.dev rather
> than have a glibc subdomain.  Plus isn't glibc on the mailing list
> name and the domain redundant?

The subdomain facilitates different projects making different hosting 
choices in future (via DNS changes) if they wish without needing to make 
further changes to email addresses.

The use of glibc in the list names is formally redundant, but we felt it 
was convenient for informal references to the lists in text, email client 
aliases, etc. to be able to talk about e.g. glibc-devel and have it 
unambiguous rather than just talking about devel@ which could refer to 
multiple projects.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Andrea Pinski via Gdb]

On Tue, Sep 22, 2026 at 11:34 AM Joseph Myers <josmyers@redhat.com> wrote:
>
> On Mon, 21 Sep 2026, Andrea Pinski wrote:
>
> > >   * Discuss on libc-alpha finalize mailing list names:
> > >    * Place mailing list services under lists.glibc.coretoolchain.dev
> > >    * glibc-announce@lists.glibc.coretoolchain.dev
> > >    * glibc-devel@lists.glibc.coretoolchain.dev
> > >    * glibc-stable@lists.glibc.coretoolchain.dev
> > >    * glibc-testresults@lists.glibc.coretoolchain.dev
> > >    * glibc-help@glibc.lists.glibc.coretoolchain.dev
> > >    * glibc-vcs@lists.glibc.coretoolchain.dev
> >
> > Especially here about why not just have lists.coretoolchain.dev rather
> > than have a glibc subdomain.  Plus isn't glibc on the mailing list
> > name and the domain redundant?
>
> The subdomain facilitates different projects making different hosting
> choices in future (via DNS changes) if they wish without needing to make
> further changes to email addresses.
>
> The use of glibc in the list names is formally redundant, but we felt it
> was convenient for informal references to the lists in text, email client
> aliases, etc. to be able to talk about e.g. glibc-devel and have it
> unambiguous rather than just talking about devel@ which could refer to
> multiple projects.

So there was no consensus on the community members except for the ones
who were at the meeting?
Ok. I think that it is wrong to have separate domains.  The moving
part is a bad reason for having a seperate domain. If we have a
separate domain the redundant part is just broken and maybe better
names could come up with.

Also why NOT use a forge for patches instead of pushing for mailing lists?
Also why NOT just one email list?  Why 6 mailing lists?
What is the need for glibc-stable?
Maybe glibc-testresults should not be a mailing list but rather a
better way of collecting test results and displaying them?

>
> --
> Joseph S. Myers
> josmyers@redhat.com
>

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[DJ Delorie via Gdb]

On Tue, Sep 22, 2026 at 3:03 PM Andrea Pinski via Binutils
<binutils@sourceware.org> wrote:
> So there was no consensus on the community members except for the ones
> who were at the meeting?

You would prefer "so there was no consensus except for the ones who
were on the mailing list" ?

Carlos and Mark have both been diligent in announcing these meetings
and posting minutes.  If you choose to ignore them, that's on you.

> Ok. I think that it is wrong to have separate domains.

I think it's inevitable.

> Also why NOT just one email list?  Why 6 mailing lists?

Why not 47?  Why not zero?  If you have a specific request, please
make it and justify it.  We have an *opportunity* to reorganize
mailing lists if/when we move the mail servers, but we *can*
reorganize the lists any time we want, too.

> What is the need for glibc-stable?

Downstream maintainers who need to watch for bugfixes.  I would hope
by now everyone would know this.

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Andrea Pinski via Gdb]

On Tue, Sep 22, 2026 at 12:14 PM DJ Delorie <dj@redhat.com> wrote:
>
> On Tue, Sep 22, 2026 at 3:03 PM Andrea Pinski via Binutils
> <binutils@sourceware.org> wrote:
> > So there was no consensus on the community members except for the ones
> > who were at the meeting?
>
> You would prefer "so there was no consensus except for the ones who
> were on the mailing list" ?
>
> Carlos and Mark have both been diligent in announcing these meetings
> and posting minutes.  If you choose to ignore them, that's on you.

Hmm, no carlos has been diligent in announcing the meetings.  Also it
conflicts with many other meetings I have.  And it is NOT a time that
is viable for me.
So I have not chosen to ignore them.  And now you are dictating how
this consensus should be brought together in the same way you mention
Zack is doing.

>
> > Ok. I think that it is wrong to have separate domains.
>
> I think it's inevitable.
>
> > Also why NOT just one email list?  Why 6 mailing lists?
>
> Why not 47?  Why not zero?  If you have a specific request, please
> make it and justify it.  We have an *opportunity* to reorganize
> mailing lists if/when we move the mail servers, but we *can*
> reorganize the lists any time we want, too.

Right and that is my point this should be a separate unrelated
discussion rather there are many different discussions going on and
things are being tied to the move for no reason.

>
> > What is the need for glibc-stable?
>
> Downstream maintainers who need to watch for bugfixes.  I would hope
> by now everyone would know this.

Why not just use -announcement for that?

>

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Siddhesh Poyarekar]

On 2026-09-22 15:22, Andrea Pinski wrote:
>>> What is the need for glibc-stable?
>>
>> Downstream maintainers who need to watch for bugfixes.  I would hope
>> by now everyone would know this.
> 
> Why not just use -announcement for that?
-announce has a completely different audience and has very low volume. 
It is limited to significant events, like release announcements and 
security advisory announcements.

Sid

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Joseph Myers via Gdb]

On Tue, 22 Sep 2026, Andrea Pinski wrote:

> So there was no consensus on the community members except for the ones
> who were at the meeting?

It makes a lot more sense to work out a coherent list of mailing list 
names (this is about the names, the actual set of lists has already been 
discussed on libc-alpha based on a proposal we made at an earlier stage) 
in a small group rather than bikeshedding naming in a long thread on a 
large mailing list.

> Also why NOT use a forge for patches instead of pushing for mailing lists?

There are plenty of uses for discussions not associated with a particular 
patch.  A forge might be a replacement for patchwork, but not for mailing 
lists.

> Also why NOT just one email list?  Why 6 mailing lists?
> What is the need for glibc-stable?

We already discussed the set of mailing lists on libc-alpha in May / June.  
Based on that discussion, we concluded that libc-stable was of use 
separately from the main development list, but that libc-locales and 
glibc-bugs-regex should be closed.  There was a further opportunity for 
discussion of the closure of those two lists, which I don't think saw any 
objections.

-- 
Joseph S. Myers
josmyers@redhat.com

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Mark Wielaard]

Hi Andrea,

On Tue, 2026-09-22 at 12:02 -0700, Andrea Pinski via Gdb wrote:
> So there was no consensus on the community members except for the ones
> who were at the meeting?
> Ok. I think that it is wrong to have separate domains.  The moving
> part is a bad reason for having a seperate domain. If we have a
> separate domain the redundant part is just broken and maybe better
> names could come up with.
> 
> Also why NOT use a forge for patches instead of pushing for mailing lists?
> Also why NOT just one email list?  Why 6 mailing lists?
> What is the need for glibc-stable?
> Maybe glibc-testresults should not be a mailing list but rather a
> better way of collecting test results and displaying them?

I think I understand your point, but I think you are not expressing it
very clearly because these questions are phrased rhetorically or
sarcastically (at least that is how they read to me). Now people are
just answering your questions as if they are part of the disputed
proposal.

But all of these questions can (and should) be decided separately.
glibc is already setup on the forge https://forge.sourceware.org/glibc
Currently it is only used as stable mirror. But if someone wants to
experiment with merge requests we can install some of the bots/tools
gcc has been using. If any list should be closed, archived,
renamed/split we can easily do that, no need to move infrastructure.
glibc buildbot results are already going into bunsen
https://builder.sourceware.org/testruns/ connecting patchwork and
buildbot is a work in progress.

Cheers,

Mark

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Siddhesh Poyarekar]

On 2026-09-22 15:02, Andrea Pinski wrote:
>> The use of glibc in the list names is formally redundant, but we felt it
>> was convenient for informal references to the lists in text, email client
>> aliases, etc. to be able to talk about e.g. glibc-devel and have it
>> unambiguous rather than just talking about devel@ which could refer to
>> multiple projects.
> 
> So there was no consensus on the community members except for the ones
> who were at the meeting?

There was a loose consensus among those present at the meeting (Carlos, 
myself and Joseph).  I had leaned towards not having subdomains when 
Konstantin said that configuration would be more convenient to support 
vs subdomains, but aligned with Joseph's position when he explained it.

> Ok. I think that it is wrong to have separate domains.  The moving
> part is a bad reason for having a seperate domain. If we have a
> separate domain the redundant part is just broken and maybe better
> names could come up with.

Why is it broken?  Could you suggest better names?  I think 
ease/independence of movement is a great reason to have separate 
subdomains and more importantly, is more than just a personal preference.

> Also why NOT use a forge for patches instead of pushing for mailing lists?

That's not a CTI question, that's a community question.  With my glibc 
contributor hat on, I don't think it's an either-or question.

> Also why NOT just one email list?  Why 6 mailing lists?
> What is the need for glibc-stable?

DJ already answered this; glibc-stable is actively used by downstream 
developers.  I won't object if there's consensus towards folding it into 
libc-alpha, but that would mean dozens of additional (likely irrelevant 
for others) messages on the list.  That said though, I do like the idea 
of the original patch and backports all living in the same list, ideally 
with a `References` tag linking them up since that would make processing 
them so much easier, especially for security fixes.

As an aside, I had riffed on the idea in the past of a bot sending out 
[committed] emails to libc-alpha whenever there's a commit that did not 
land on the mailing list first.  I ended up write a cron job for myself 
to track this, which isn't very useful anymore since we're not doing 
anything with that information.

Maybe we could finally implement that *and* make the libc-stable 
messages entirely bot-driven so that contributors doing backports have 
one less step to do?

> Maybe glibc-testresults should not be a mailing list but rather a
> better way of collecting test results and displaying them?
There's bunsen, but again, that's not an either-or question.  We can 
always shut down the mailing list if we decide that it's not in use 
anymore.  I don't think anybody has actually looked at that lately.

Thanks,
Sid

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Siddhesh Poyarekar]

On 2026-09-24 11:15, Siddhesh Poyarekar wrote:
>> Maybe glibc-testresults should not be a mailing list but rather a
>> better way of collecting test results and displaying them?
> There's bunsen, but again, that's not an either-or question.  We can 
> always shut down the mailing list if we decide that it's not in use 
> anymore.  I don't think anybody has actually looked at that lately.
Of course, I was wrong (as Joseph pointed out elsewhere) and all of the 
mailing lists were put on the table for review here:

https://inbox.sourceware.org/libc-alpha/932cc126-4a9a-4507-9c26-2c13524100d0@redhat.com/

Sid

Re: Meeting Minutes - Office Hours for CTI - 2026-09-18

[Carlos O'Donell via Gdb]

On 9/24/26 11:15 AM, Siddhesh Poyarekar wrote:
> On 2026-09-22 15:02, Andrea Pinski wrote:
>> Also why NOT just one email list?  Why 6 mailing lists? What is the
>> need for glibc-stable?
> 
> DJ already answered this; glibc-stable is actively used by downstream
> developers.  I won't object if there's consensus towards folding it
> into libc-alpha, but that would mean dozens of additional (likely
> irrelevant for others) messages on the list.  That said though, I do
> like the idea of the original patch and backports all living in the
> same list, ideally with a `References` tag linking them up since that
> would make processing them so much easier, especially for security
> fixes.

We had an on-list discussion *specifically* about this topic in May 2026.

"[RFC] How many mailing lists does glibc need or use? Closing 4 lists."
https://inbox.sourceware.org/libc-alpha/932cc126-4a9a-4507-9c26-2c13524100d0@redhat.com/

I received feedback from Collin, and Arjun.

Then again to discuss closing some lists:

"[RFC] Closing libc-locales and glibc-bugs-regex mailing lists at the end of June 2026."
https://inbox.sourceware.org/libc-alpha/91482a3d-3abb-469e-9616-da83559f7e6a@redhat.com/

(which still need to be closed, TODO item for me).

-- 
Cheers,
Carlos.