[RFC] How many mailing lists does glibc need or use? Closing 4 lists.

[Collin Funk]

Hi Carlos,

Carlos O'Donell <carlos@redhat.com> writes:

> Could we reduce our lists to just:
>
>    libc-announce - Announcements.
>    libc-alpha - Development on any branch.
>    libc-testresults - Large volume post-commit CI test results.
>    libc-help - Developer help
>    glibc-cvs - Commit list for monitoring.
>    glibc-bugs - Bug tracking to email.
>    libc-maintainers@gnu.org - Reaches current and past GNU Project maintainers.
>
> Closing the following 4 lists since they don't meet the above goals:
>
>    libc-stable - Should go to libc-alpha.
>    libc-locales - Should go to libc-alpha.
>    glibc-bugs-regex (limited bugs just for regex) - Should go to bugzilla or libc-help.

Closing libc-locales and glibc-bugs-regex seems obvious to me, since
bugs should go to bugzilla and questions are more likely to be answered
on libc-alpha which is more closely tracked (at least by me, but likely
by others as well).

> Notes:
> - Merging libc-stable traffic to libc-alpha means you have one less
>   list to review as a developer. This means just one list to look for
>   reviews and one less list to handle for pre-commit CI which can review
>   per-branch CI e.g. consistent rules for patch naming so CI can decide
>   on the branch. There should be ONE email you can subscribe to for
>   development work for master or stable branches or any branch for the
>   matter.

I'm not too familiar with the libc-stable list. If I remember correctly,
it has quite a bit of activity. I think there is some benefit to keeping
a more focused list for that. However, your rationale makes sense as
well. Lets see what others think.

Collin