Re: [gentoo-dev] New ALSA maintainers

[Daniel Drake]

Jakub Moc wrote:
> It not only doesn't work for me,

Bug please! :)

> it doesn't work for majority of people
> that have responded on this thread. So, something's wrong there I guess? :)

I don't regard this thread as quantifiable measure. Nevertheless, lets 
count the number of successes and failures on this thread so far:

jakub: failure
aslandis: failure
cardoe: failure

wltjr: success
nightmorph: success
seemant: success
kloeri: success
uberlord: success

gentoodoo: 1 each way

I'm not asking for more people to add experiences, and I'm not saying 
that in-kernel is any more reliable than alsa-driver. I'm just pointing 
out how easy it is to misinterpret the information on a thread, and how 
you cannot make the above statement.

Maybe this wasn't a serious comment, in which case I apologise for 
taking it seriously. Email sucks for communication.

> Hmmm, I'm not entirely sure what are you responding to here? What I said
> was that "ALSA upstream won't accept bugs about in-kernel drivers" - now
> how's that related to whether you (or kernel upstream) support them or not?

Sorry, I can see how my response wasn't clear.

When I say "I support" I mean that I accept the bugs on Gentoo bugzilla 
and work them through til resolution. So, you're correct that me 
supporting something is not related to any decisions made upstream.

However, many bugs which pass through my "support" follow a common 
pattern: I request lots of useful info, am not able to immediately solve 
the problem myself, so I instruct the user how to file the bug upstream. 
In most cases they do so, and I track the upstream bug. And it's these 
cases I'm referring to - I've never seen any upstream bugs rejected due 
to them using in-kernel drivers.

Please understand that it wouldn't make much sense for them to reject it 
either. There is no difference personnel-wise between the people who 
release alsa-driver and the people who send patches into the kernel. If 
they were to refuse bugs from people who use kernel drivers then why do 
they spend a considerable amount of time regularly synchronising patches?

> Additionally - forcing people to upgrade kernel for their sound issues
> is not a solution for many of them. Kernel upgrades tend to break lots
> of stuff on every minor version bump (and it's not only external modules
> that upstream seems to plain hate and ignore mostly). Not exactly what
> users would like to see when all they are trying to get is working
> sound.

Beyond the usual statements that we aren't forcing anything:

I will not deny that there is some user convenience gained by having the 
drivers separated from the kernel. Conversely, such packages are 
maintenance nightmares and are susceptible to entire classes of bugs 
that they would not be otherwise, and these are often passed onto the 
user. Sometimes we are even forced to take drastic measures such as 
marking heavily experimental code stable.

The problem I'm solving here, I am solving from a development 
perspective. We have duplicated code and duplicated effort, and one of 
the copies currently doesn't have any real manpower taking care of it.

 > Plus it's lot easier (and faster) to get patches into external
> drivers than get them accepted into kernel.

I'm not sure that it is any easier, because the process of patch 
submission (file a bug) is the same.

It may be faster, but I don't think thats a big factor. We generally do 
a good job keeping on top of the kernel bug list and regularly doing 
bugfix kernel releases. Although it may be faster for maintainers to 
supply new packages like alsa-driver, it's not *that* much different.

All of the complaints so far seem to be regarding that *handling bugs* 
is more convenient for certain use cases when supported ALSA drivers are 
provided by an out-of-kernel package. (for clarity: a kernel driver not 
working IS a kernel bug, even if you have alternative ways of getting 
that hardware working)

There is some truth here. However, more importantly in my eyes, our 
development resources are thin and there are currently 0 people standing 
behind alsa-driver. Additionally our processes across the entire Gentoo 
tree are based on the assumptions that things work, and bugs are treated 
as exceptions. Sure, we accept that bugs exist, and there are plenty of 
them, and we look to improve our methods of handling them (I have 
certainly done this a lot for the kernel) but we don't revolve our 
entire system around the assumption that the packages in the stable tree 
have bugs.

What I'm trying to say is that even though there are some downsides 
here, the overall process is improved given the resources we have.

Even though I'm sure my personal opinion is clear, I don't have a strong 
stake in the ALSA herd. The real reason why alsa-driver is not getting 
any support behind it right now is that nobody is standing behind it.

If someone wants to step up and take over maintenance of alsa-driver, 
and put the required amount of time/effort into maintaining such a large 
kernel code base outside of the kernel, then I can accept that. I can 
accept that not everyone shares my views, and although I unintentionally 
managed to frustrate the previous maintainer a few times, I did accept 
that he was willing to stick by ideas just as I was prepared to stick by 
mine.

That said, the newly formed ALSA herd seems to share my opinion and 
don't seem prepared to properly maintain alsa-driver, so I can see it 
slowly becoming lesser supported. If anyone wants to change this, 
approach the 3 developers listed in my original mail, share your ideas, 
and see if you can help out with ALSA maintenance and apply your ideas.

>  > Interestingly in this case, the in-kernel driver is a touch newer than
>> the hda-intel one. It includes support for a few more hardware devices.
>> Again these are only very small differences though.
>
> As said, it's not about code being newer or older, it's about having two
> different branches of the code.

Agreed. As stated, the point I was making is that they are the same 
codebase. The above was just an interesting but unrelated observation, 
sorry if I threw you off track.

> One works for someone, the other works
> for someone else. What's exactly the benefit from trying to kill support
> for upstream ALSA code and forcing people to use in-kernel drivers
> (beyond what you see as 'duplicated' maintenance effort)? Users honestly
> don't care much about 'duplicated' effort, they want a working sound on
> their boxes.

This is a very valid concern. My view is certainly affected by 2 years 
of kernel bug handling and not really seeing the issues that people 
describe (where alsa-driver works and in-kernel does not for something 
other than user error) with any regularity.

There are reasons that I am still working on kernel bugs after 2 years 
though. Firstly, the kernel code base is of personal interest to me, and 
I enjoy being part of the upstream community and finding more ways to 
contribute. Secondly, I enjoy a challenge and I enjoy the problem 
solving aspect of handling bugs. Kernel bugs are great brain food and I 
like seeing them through.

So, I will put forward a claim, which you are free to regard as 
completely ridiculous:

Everyone who is claiming that alsa-driver works and in-kernel does not:
  a) has not actually tried both
or
  b) has tried both but has only attempted to reproduce the issue on 1,
     or is otherwise mistaken about their issue which does infact exist
     in both "codebases" (I quote that word as I interpret them as the
     same)
or
  c) is attempting to use the wrong module, or is mixing alsa-driver and
     in-kernel modules, or is otherwise making a user-level error
or
  d) is referring to a large difference in driver versions (e.g. 2.6.3
    does not work but alsa-driver does! or maybe not quite that extreme!)
or
  e) is not comparing the same environments (my card works fine in
     alsa-driver on System A, but does not work with in-kernel drivers on
     System B, therefore alsa-driver works and in-kernel does not!)
or
  f) is LYING

I'm fully 100% serious on the above. I challenge you to PROVE ME WRONG. 
I secretly hope you do, since that means I'll get a couple of 
interesting bugs to handle and I may even be able to solve them myself.

Thanks,
Daniel
-- 
gentoo-dev@g.o mailing list