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@xxxxxxxx) 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. That's true. > 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 > vastly: > > - properly create a mail per entry > currently mantis mail notification is broken and useless Seems that mantis developers are aware of this now: http://www.mantisbt.org/wiki/doku.php/mantisbt:diff_emails_requirements > - 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 ----- Jaroslav Kysela <perex@xxxxxxxx> Linux Kernel Sound Maintainer ALSA Project _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
