| 1 |
Daniel Drake wrote: |
| 2 |
> I have suggested that herd support for the kernelspace side |
| 3 |
> (alsa-driver) be slowly reduced, by redirecting users who file bugs |
| 4 |
> against it to reproduce with the in-kernel drivers, and then let kernel |
| 5 |
> handle the bug resolution. This will remove duplicated maintenance |
| 6 |
> efforts. |
| 7 |
> |
| 8 |
This is perfectly reasonable where it is a card with drivers in both, but |
| 9 |
alas-drivers supports a broader range of hardware, eg the echo audio cards |
| 10 |
(guess who has one ;) which have never been available in-kernel. |
| 11 |
|
| 12 |
> This will also mean no more stabling of -rc releases (and probably fewer |
| 13 |
> of those in portage at all). |
| 14 |
> |
| 15 |
Sounds fine. |
| 16 |
|
| 17 |
> alsa-driver won't be going away altogether, as it is still needed for |
| 18 |
> 2.4 users (but we won't support them forever) and I think it may include |
| 19 |
> a couple of drivers which aren't yet in the kernel tree. |
| 20 |
> |
| 21 |
So the bug resolution for cards with drivers _not_ in the kernel will be to |
| 22 |
pass them upstream if they are reproducible? |
| 23 |
I guess I'd like some assurance that as long as alsa-drivers supports |
| 24 |
hardware for which there are no kernel drivers, it will at least be |
| 25 |
available in the portage tree. |
| 26 |
|
| 27 |
It might be worth stripping duplicate drivers out of alsa-drivers altogether |
| 28 |
so that the two might even co-exist? Would eliminate the bug duplication in |
| 29 |
any event. From what I've read in this thread, the only area of difficulty |
| 30 |
would be new chipsets, but then there'd be more developer time with less |
| 31 |
bugs, and that seems to be the way things are going anyhow. |
| 32 |
|
| 33 |
Thanks for all your hard work on the kernel. |
| 34 |
|
| 35 |
|
| 36 |
-- |
| 37 |
gentoo-dev@g.o mailing list |
Archives