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

[DJ Delorie via Gdb <gdb@sourceware.org>]

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.