New ALSA Herd

So, after today fixes to sound bugs, I started thinking on how to improve the feedback with bugs currently assigned to the Sound team. One thing I thought about is a re-organisation of ALSA packages, trying to allow a broader collaboration of developers, trying to close the issue with in-kernel drivers versus external drivers.

Let’s try to summarise what my line of thinking is. Before today, ALSA packages were maintained by the Sound team. The problem is that the team is staffed, but mostly for userland utilities, none of them ever looked at ALSA packages up to now, and this is understandable. The kernel team of course cannot get address to check the ALSA support themselves, and who wants to help with just ALSA had to receive a lot of bugspam related to other things.

What I’m trying to do is a sort of divide et impera method, by splitting the ALSA support on its own herd (alsa herd, alias) that will take care of all the ALSA packages themself. This reduces the bugspam received by who wants to help with ALSA, and will allow Kernel folks to join it and help, too 🙂

The result is that, if my idea works, it will be possible to support both in-kernel and alsa-drivers provided modules, without fighting with each other anymore 🙂