Bug tracking?

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

Re: [Fwd: Re: [Jackit-devel] OSS Backend]

[Takashi Iwai]

At Thu, 15 May 2003 15:07:33 +0900,
Patrick Shirkey wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> Before I do this do you think it will be useful or used?
> 
> Specifically Jaroslav and Takashi....
> 
> [2 Re: [Jackit-devel] OSS Backend <message/rfc822 (7bit)>]
> To: Nathaniel Gray <n8gray@caltech.edu>
> CC: jackit-devel@lists.sourceforge.net
> Subject: Re: [Jackit-devel] OSS Backend
> From: Patrick Shirkey <pshirkey@boosthardware.com>
> Message-ID: <3EC32AE8.8070504@boosthardware.com>
> Date: Thu, 15 May 2003 14:51:36 +0900
> Organization: Boost Hardware
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1)
>  Gecko/20020826
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> Nathaniel Gray wrote:
> > 
> > I would agree if the ALSA drivers were more reliable, but from what I've 
> > seen that's not always the case.  The ALSA developers seem to have 
> > their hands full, bug reports are not handled in any kind of organized 
> > way and are thus regularly dropped.  
> >
> 
> 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.


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

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: Re: bug tracking?

[Takashi Iwai]

At Thu, 15 May 2003 19:12:26 +0900,
Patrick Shirkey wrote:
> > - 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.

yes, a script would be nice.

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

the system like bugzilla can communicate via e-mails, too.

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

i'm familiar with bugzilla (not as an adamin but as a user :) and am
satisfied almost with it.  it's enough powerful.
but bugzilla has many configurations and we'll need to find out the
fitting one for our purpose.


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: Re: bug tracking?

[Patrick Shirkey]

Takashi Iwai wrote:

> 
> i'm familiar with bugzilla (not as an adamin but as a user :) and am
> satisfied almost with it.  it's enough powerful.
> but bugzilla has many configurations and we'll need to find out the
> fitting one for our purpose.

I'm looking at it now. The first thing that jumps out at me is that all 
users have to login to make a submission online.

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.

If we use bugzilla I will need full access to the mysql database on the 
server. I could code something with less features in php. It would work 
slower but it will work.

Of course I would much prefer to have access to the mysql database as I 
can do some other funky things for the install docs then too. Like a 
card rating system.

I have written to Jaroslav about this before but have never received an 
answer. I realise that I could be a huge security risk but I'm happy to 
sign some papers if that is what is required. I will send you my PO box 
address privately if that needs to be done.

So my Suse friends. What does the boss say?


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



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

Re: Re: bug tracking?

[Takashi Iwai]

At Tue, 20 May 2003 11:01:21 +0900,
Patrick Shirkey wrote:
> 
> Takashi Iwai wrote:
> 
> > 
> > i'm familiar with bugzilla (not as an adamin but as a user :) and am
> > satisfied almost with it.  it's enough powerful.
> > but bugzilla has many configurations and we'll need to find out the
> > fitting one for our purpose.
> 
> I'm looking at it now. The first thing that jumps out at me is that all 
> users have to login to make a submission online.

iirc, the current sf system requires also account..?

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

> If we use bugzilla I will need full access to the mysql database on the 
> server. I could code something with less features in php. It would work 
> slower but it will work.
> 
> Of course I would much prefer to have access to the mysql database as I 
> can do some other funky things for the install docs then too. Like a 
> card rating system.
> 
> I have written to Jaroslav about this before but have never received an 
> answer. I realise that I could be a huge security risk but I'm happy to 
> sign some papers if that is what is required. I will send you my PO box 
> address privately if that needs to be done.
> 
> So my Suse friends. What does the boss say?

the alsa-project.org is managed by Jaroslav, and it's outside of
SuSE.  so, the permission you can take is up to Jaroslav.

i think it's possible to provide a server space for this by SuSE, too,
if necessary.  (for example, xfree86 cvs server is running on suse
machines.)


Takashi


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

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