bug tracking?

bug tracking?

[Jaroslav Kysela]

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).

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

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
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

Re: bug tracking?

[Takashi Iwai]

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

Re: bug tracking?

[Patrick Shirkey]

Takashi Iwai wrote:
>>
>>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).
> 

We also have the added difficulty of making sure each driver is 
adaquately covered by the system.

> - no template for necessary information
> 
>   e.g. alsa version, driver, chip/board name/model, output of lspci
>        output of proc files, etc.
> 

These could easily be found with a simple script or maybe there couold 
be an alsa.debug file in /proc/asound.

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

How about having a bugs mailing list and also the address of the driver 
writer. We could then post the report to the mailing list, the driver 
writer and also archive it on the alsa website.

I will start making a bugs page over the next few days which we can fine 
tune here. I'm not sure that bugzilla is appropriate for ALSA as we have 
so many different devices to look after however I will use it as a 
reference.


-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
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

Re: bug tracking?

[Erik Inge Bolsø]

On Tue, 20 May 2003, Takashi Iwai wrote:
>At Tue, 20 May 2003 11:01:21 +0900,
>Patrick Shirkey wrote:
>> IMO that will make it less likely for people to submit reports. However
>> the rest of the system is very slick so I'm not sure what direction to
>> take. There doesn't seem to be a way to turn of the login as it seems to
>> be crucial to making sure the system works.
>
>i don't think the account makes any problem.  any bug reporter should
>be responsible also for answering / following the thread.  the
>anonymous account makes it difficult.
>also, if someone is lazy, there is still mailing list for help :)

I tend to disagree. Logging in on a website is an annoyance. Providing a
valid email address for the followup discussion, however, is perfectly
acceptable. Some bug tracking systems create ephemeral mailing lists for
every bug, log any discussion on that mailing list as related to that
bug... and add anyone seen in CC: to the same mailing list. Don't
remember the bug system's name right now, sorry.

But it strikes me as an elegant way of doing it.

--
Erik I. Bolsø | email: <knan at mo.himolde.no>
The UNIX philosophy basically involves giving you enough rope to
hang yourself.  And then a couple of feet more, just to be sure.


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Bug tracking?

[Michael Tokarev]

So, what's the current state of the bug tracking system?
As far as I can see, qemu is moving to launchpad.
Where qemu-kvm-related issues should be submitted nowadays?

Thanks!

/mjt

Re: Bug tracking?

[Anthony Liguori]

On 05/21/2010 07:45 AM, Michael Tokarev wrote:
> So, what's the current state of the bug tracking system?
> As far as I can see, qemu is moving to launchpad.
> Where qemu-kvm-related issues should be submitted nowadays?

Kernel issues should be filed in bugzilla.kernel.org.

qemu issues should be filed in LaunchPad.

Regards,

Anthony Liguori

> Thanks!
>
> /mjt
> -- 
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug tracking?

[Avi Kivity]

On 05/21/2010 06:50 PM, Anthony Liguori wrote:
> On 05/21/2010 07:45 AM, Michael Tokarev wrote:
>> So, what's the current state of the bug tracking system?
>> As far as I can see, qemu is moving to launchpad.
>> Where qemu-kvm-related issues should be submitted nowadays?
>
> Kernel issues should be filed in bugzilla.kernel.org.
>
> qemu issues should be filed in LaunchPad.
>

qemu-kvm issues, even if not present in upstream qemu, should be filed 
in launchpad (but clearly marked to be qemu-kvm specific).

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: Bug tracking?

[Michael Tokarev]

21.05.2010 19:56, Avi Kivity wrote:
> On 05/21/2010 06:50 PM, Anthony Liguori wrote:
>> On 05/21/2010 07:45 AM, Michael Tokarev wrote:
>>> So, what's the current state of the bug tracking system?
>>> As far as I can see, qemu is moving to launchpad.
>>> Where qemu-kvm-related issues should be submitted nowadays?
>>
>> Kernel issues should be filed in bugzilla.kernel.org.
>>
>> qemu issues should be filed in LaunchPad.
>
> qemu-kvm issues, even if not present in upstream qemu, should be filed
> in launchpad (but clearly marked to be qemu-kvm specific).

Aha. That makes perfect sense now.  Thanks!

/mjt