All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Jaroslav Kysela <perex@suse.cz>
Cc: Patrick Shirkey <pshirkey@boosthardware.com>,
	ALSA development <alsa-devel@alsa-project.org>
Subject: Re: bug tracking?
Date: Thu, 15 May 2003 11:37:49 +0200	[thread overview]
Message-ID: <s5hznloeej6.wl@alsa2.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0305151112200.9877-100000@pnote.perex-int.cz>

At Thu, 15 May 2003 11:21:37 +0200 (CEST),
Jaroslav wrote:
> 
> On Thu, 15 May 2003, Takashi Iwai wrote:
> 
> > > Maybe that should be my next addition to the ALSA website. I get a lot 
> > > of bug reports through the docs page and it makes sense to reuse that 
> > > code for a bug reporting system.
> > > 
> > > Maybe it will have more psychological impact if it is hosted by ALSA 
> > > instead of sf.net (which seems to always have something wrong with it 
> > > anyway).
> > 
> > it would be really appreciated.
> > i personally dislike the current sf's bug-reporting system.
> 
> The question is, if we have power to maintain such large bug reports.
> From my experience, it works only few weeks until the system has many 
> unresolved reports. Then the database gets filled and only some bugs are 
> solved when our time permits. Also, when the database is large, it is
> a bit problematic to mark solved reports (especially old ones).

that's true.

i think the current sf system has the following problems.

- poor resolution of bugs

  for example, in the case of bugzilla, we can mark the items in
  better way: if you want to leave it, you can set LATER, WORKSFORME
  or REMIND.  also, many of bug reports may be marked as DUPLICATED.

- restricted (re)assignment

  if a bug is assigned to another person, you cannot resolve it.

- no structured view (classification)

  all the bugs are listed in a flat list.  too difficult to find
  a single bug.

- no mail communications

  only the web is access to the system.

- no template for necessary information

  e.g. alsa version, driver, chip/board name/model, output of lspci
       output of proc files, etc.


also, a moderator person would be helpful in addition to the automatic
assignment according to the given driver/function.

another interesting idea is to have a "tester" list for each driver.
when a bug report which is specific to a driver comes, it's delivered
to all testers (and the maintainer) of the driver, so that they can
check and follow up whether it works for them.


> I also think that we should definitely create a document what users should 
> describe to avoid many communication handshakes with the bug reporter.

providing a template would help for such a case, i believe.


Takashi


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

  reply	other threads:[~2003-05-15  9:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15  6:07 [Fwd: Re: [Jackit-devel] OSS Backend] Patrick Shirkey
2003-05-15  8:58 ` Takashi Iwai
2003-05-15  9:21   ` bug tracking? Jaroslav Kysela
2003-05-15  9:37     ` Takashi Iwai [this message]
2003-05-15 10:12       ` Patrick Shirkey
2003-05-15 12:53         ` Takashi Iwai
2003-05-20  2:01           ` Patrick Shirkey
2003-05-20 11:34             ` James Courtier-Dutton
2003-05-20 13:25               ` Patrick Shirkey
2003-05-20 14:11             ` Takashi Iwai
2003-05-20 14:51               ` Erik Inge Bolsø
2003-05-20 16:16                 ` Patrick Shirkey
2003-05-20 16:46                 ` Paul Davis
2003-05-20 16:02               ` Patrick Shirkey
  -- strict thread matches above, loose matches on Subject: below --
2010-05-21 12:45 Bug tracking? Michael Tokarev
2010-05-21 15:50 ` Anthony Liguori
2010-05-21 15:56   ` Avi Kivity
2010-05-21 16:12     ` Michael Tokarev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hznloeej6.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=perex@suse.cz \
    --cc=pshirkey@boosthardware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.