On Thu, Oct 19, 2023 at 03:57:35PM +0200, Jaroslav Kysela wrote: > > I'm told that a while back there were some discussions to migrate this list to > > vger, but the process never really got finalized. > > > > I would like to restart this discussion again, because I am in the middle of > > vger list migrations and it seems like an opportune moment to bring this up. > > > > There are the following benefits to gain after migration: > > > > - it becomes an open list that doesn't require much moderator involvement > > I think that it may be the main reason to migrate it. How do you handle the > inbound spam? It's the only reason, why our mailing list is moderated. We do allow a small amount of spam through, unfortunately, but the combination of aggressive blocklist checking, spam filtering, and strict content policies allow us to keep that volume pretty low (1-2 messages a week for most lists). > > - we can try to set up a forward from the old address, but previous attempts > > to do so with mailman had mixed results > > - if the old address is set up to forward mail to the new address, then anyone > > sending to both addresses will get doubles of everything, which can be > > annoying > > - setting up a hard bounce at the old address would probably be preferable, > > but it's a "ripping off the bandaid" kind of approach > > Ideally, the e-mail address of the list should be preserved, but I guess > that an option to redirect DNS MX records to LF servers is not possible, > right? Well, it's possible, but that would require us handling all of alsa-project.org mail, and it's probably not what you want. We *can* set things up so we treat alsa-project.org as an internal relay, and then you just pass alsa-devel@xxxxxxxxxxxxxxxx to our lists server, but this is somewhat fragile as well. There's a third option -- instead of migrating the alsa-devel list, we can migrate all activity to linux-sound@xxxxxxxxxxxxxxx. It's an existing list that currently sees about 5 messages a year (and most of them are cc'd to alsa-devel anyway). The process would be: 1. Set up https://patchwork.kernel.org/project/alsa-devel/ to source from two lists instead of just alsa-devel (we do this already for netdev, which sources from both netdev and bpf lists) 2. Change all MAINTAINERS entries from alsa-devel to linux-sound 3. Eventually, this will result in almost no patches being sent to alsa-devel, at which point we can evaluate if the alsa-devel list sees little enough traffic that it can just be closed or redirected I think this option is worth considering because it will achieve the desired effect of removing moderation on submitted patches, keep existing maintainer workflows, and not require actually migrating the alsa-devel list. Thoughts? -K
