[alsa-devel] If /dev/snd/controlCx EACCES vs. ENODEV mixup
perex at perex.cz
Mon Nov 26 08:47:12 CET 2007
On Mon, 26 Nov 2007, Takashi Iwai wrote:
> At Sun, 25 Nov 2007 22:53:00 +0100,
> Lennart Poettering wrote:
> > On Sun, 25.11.07 22:42, Jaroslav Kysela (perex at perex.cz) wrote:
> > >
> > > On Sun, 25 Nov 2007, Lennart Poettering wrote:
> > >
> > > > BTW, what's the status of the BTS? Takashi asked me to post all my
> > > > issues on the ML instead of on the BTS. So why have the BTS at all?
> > > > It's even linked on the alsa-project.org front page under "I found a
> > > > bug!", which is a bit misleading. If this Mantis thing is not liked at
> > > > all, would it be possible to make some replacement available? Maybe
> > > > just use the kernel bugzilla on bugzilla.kernel.org? It's very fast,
> > > > and certainly more fun to work with than with Mantis.
> > >
> > > I prefer BTS but Takashi not. It's matter of personal preference. Mantis
> > > is easy maintainable and we have more projects (or packages) not only
> > > drivers.
> > The kernel bugzilla already is used for stuff like klibc and other
> > userspace support code for the kernel. I am sure noone would oppose to
> > move the complete bug tracking of ALSA to the kernel bz.
> The problem is the total lack of man power for debugging.
> You'll understand easily if you see too many open bugs. And the bug
> report quality isn't always good. Many reports, e.g. about HD-audio
> issue, are either too old, irrelevant, or simply unsupported device
> (or all of them are mixed up). Only a few of them are really
> interesting. But, even filtering them takes too much time.
> So, I guess it won't matter whether it's bugzilla or not. Unless
> someone sweeps bug entries regularly, BTS can't work properly.
> BTW, regarding bugzilla vs mantis. There are a few features that are
> missing in mantis. For example, the below are what I'd love to have
> - properly create a mail per entry
> currently mantis mail notification is broken and useless
Seems that mantis developers are aware of this now:
> - has optional status like NEEDINFO or WAIT_FOR_TESTING
> so we cannot mark the entries whether a user-action is required or
> not, make difficult to filter
I will add this status ASAP.
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
More information about the Alsa-devel