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