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
