Migrating this list to a different platform (take 2)
Hello, all:
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 - the messages are DMARC-compliant when received by subscribers - the infrastructure is supported and monitored by LF IT 24/7
However, there will be the following impacts:
- 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
If you are interested in migrating the list, I suggest we move it to alsa-devel@lists.linux.dev and not vger, solely because vger is in the process of migration itself and it would be easier to use the lists.linux.dev domain at this stage than to go with vger.kernel.org.
I am happy to provide any more info if you have any questions.
-K
On Tue, 17 Oct 2023 22:25:27 +0200, Konstantin Ryabitsev wrote:
Hello, all:
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
- the messages are DMARC-compliant when received by subscribers
- the infrastructure is supported and monitored by LF IT 24/7
However, there will be the following impacts:
- 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
If you are interested in migrating the list, I suggest we move it to alsa-devel@lists.linux.dev and not vger, solely because vger is in the process of migration itself and it would be easier to use the lists.linux.dev domain at this stage than to go with vger.kernel.org.
I am happy to provide any more info if you have any questions.
-K
Thanks Konstantin!
I personally find that it'd be a significant improvement to be an open list; it was often problems that manual approvals took long when admins are off due to vacation or sickness.
But the whole decision depends on Jaroslav, after all, who has been administrating the list since the beginning.
Takashi
On Thu, Oct 19, 2023 at 03:14:39PM +0200, Takashi Iwai wrote:
I personally find that it'd be a significant improvement to be an open list; it was often problems that manual approvals took long when admins are off due to vacation or sickness.
But the whole decision depends on Jaroslav, after all, who has been administrating the list since the beginning.
This is broadly my opinion also, especially with using b4 the moderation delays are noticable for me.
Hello Konstantin,
On 17. 10. 23 22:25, Konstantin Ryabitsev wrote:
Hello, all:
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.
- the messages are DMARC-compliant when received by subscribers
It seems that the mailman3 operates correctly with a simple fix.
- the infrastructure is supported and monitored by LF IT 24/7
We have no big outages for our mail list right now. The server is monitored in a hosting center, too.
However, there will be the following impacts:
- 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?
If you are interested in migrating the list, I suggest we move it to alsa-devel@lists.linux.dev and not vger, solely because vger is in the process of migration itself and it would be easier to use the lists.linux.dev domain at this stage than to go with vger.kernel.org.
I am happy to provide any more info if you have any questions.
Thank you, Jaroslav
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@alsa-project.org 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@vger.kernel.org. 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
On Thu, Oct 19, 2023 at 10:32:11AM -0400, Konstantin Ryabitsev wrote:
There's a third option -- instead of migrating the alsa-devel list, we can migrate all activity to linux-sound@vger.kernel.org. It's an existing list that currently sees about 5 messages a year (and most of them are cc'd to alsa-devel anyway).
That would definitely work well from my point of view.
On Thu, Oct 19, 2023 at 03:34:18PM +0100, Mark Brown wrote:
There's a third option -- instead of migrating the alsa-devel list, we can migrate all activity to linux-sound@vger.kernel.org. It's an existing list that currently sees about 5 messages a year (and most of them are cc'd to alsa-devel anyway).
That would definitely work well from my point of view.
Okay, since it doesn't really affect anything, I've reconfigured the patchwork side of things to accept patches sent both to alsa-devel and linux-sound. If you do want to go down the route of shifting everything towards linux-sound, the next step (once everyone is in agreement), is to make the changes to MAINTAINERS. You don't have to do all subsystems at once, you can start with the SOUND subsystem to trial things out and then shift others if everything is working correctly.
-K
On 19. 10. 23 18:25, Konstantin Ryabitsev wrote:
On Thu, Oct 19, 2023 at 03:34:18PM +0100, Mark Brown wrote:
There's a third option -- instead of migrating the alsa-devel list, we can migrate all activity to linux-sound@vger.kernel.org. It's an existing list that currently sees about 5 messages a year (and most of them are cc'd to alsa-devel anyway).
That would definitely work well from my point of view.
Okay, since it doesn't really affect anything, I've reconfigured the patchwork side of things to accept patches sent both to alsa-devel and linux-sound. If you do want to go down the route of shifting everything towards linux-sound, the next step (once everyone is in agreement), is to make the changes to MAINTAINERS. You don't have to do all subsystems at once, you can start with the SOUND subsystem to trial things out and then shift others if everything is working correctly.
If it's an overall agreement, we can move the driver related threads and the patch handling to linux-sound mailing list and keep alsa-devel list for the user space packages and the project related discussions. I'll send an initial patch for MAINTAINERS ASAP.
Jaroslav
On Fri, 20 Oct 2023 09:00:24 +0200, Jaroslav Kysela wrote:
On 19. 10. 23 18:25, Konstantin Ryabitsev wrote:
On Thu, Oct 19, 2023 at 03:34:18PM +0100, Mark Brown wrote:
There's a third option -- instead of migrating the alsa-devel list, we can migrate all activity to linux-sound@vger.kernel.org. It's an existing list that currently sees about 5 messages a year (and most of them are cc'd to alsa-devel anyway).
That would definitely work well from my point of view.
Okay, since it doesn't really affect anything, I've reconfigured the patchwork side of things to accept patches sent both to alsa-devel and linux-sound. If you do want to go down the route of shifting everything towards linux-sound, the next step (once everyone is in agreement), is to make the changes to MAINTAINERS. You don't have to do all subsystems at once, you can start with the SOUND subsystem to trial things out and then shift others if everything is working correctly.
If it's an overall agreement, we can move the driver related threads and the patch handling to linux-sound mailing list and keep alsa-devel list for the user space packages and the project related discussions. I'll send an initial patch for MAINTAINERS ASAP.
Sounds reasonable.
I'll merge your patch once after getting ACKs, but I suppose it's no urgent change and OK for 6.7 merge window?
thanks,
Takashi
participants (4)
-
Jaroslav Kysela -
Konstantin Ryabitsev -
Mark Brown -
Takashi Iwai