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

> > 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.

I remember there being an agreement, or requirement even, in the past
that all backports be announced there. However, at some point, there
was a (brief) discussion about dropping that requirement:
https://inbox.sourceware.org/libc-stable/[email protected]/

Although I don't regularly backport to release branches, I don't
remember announcing any of my recent backports on libc-stable. I
believe someone told me that the requirement was now definitely gone.
I don't remember who said it or when, but maybe during one of the
Cauldrons? I hope I am not misremembering. Anyway, looking at the list
itself, it appears that at least some of the contributors announce
their backports, but I guess many people don't.

Since most posts announce "COMMITTED" patches after the fact, the list
is just a less reliable alternative to following activity in the git
repository. For the remaining posts, libc-alpha is a reasonable list
for when a backport needs discussion/consensus.

Cheers,
Arjun