Re: [Audacity-devel] Does Bugzilla still have a case?

[James C. <cr...@in...>]

Hi Gale,

The bug list on google apps is just a quick experiment to see whether I 
could customise it to how we would want to use a bug tracker.  Some of 
the queries that can be done are linked to from:

http://code.google.com/p/audacity/wiki/BugLists

I looked at launchpad, and think it is worse for what we want to do.  I 
looked at Bugzilla and think it is a bit better, particularly with the 
bugzilla mediawiki extensions, though it would be a bit more work to set 
up and maintain.  Main plus of bugzilla over code.google is custom 
fields, though custom labels/tags in code.google do go a long way.

I've no problem if we decide to not use the code.google tracker after a 
little bit more looking into it.  If we decide not to use it we should 
delete the bugs from it to avoid confusion.  It didn't take all that 
long to put them in, and it gives us a more concrete view of what it 
would be like handling our bugs.  It shows how we might handle the 
distinction between repeatable and unrepeatable bugs and how we might 
identify regressions.

--James.


Gale Andrews wrote:
> Hi James
>
> I noticed you added all the P2s and P3s to the GoogleCode Issue Tracker
> (without thread links). I'd played cursorily with that tracker for a few
> minutes too, as you probably noticed, but did not want to spend time 
> trying it out to that extent yet. My view of the GC tracker: 
>
> * It's fairly simple, fairly customisable, and easy to change the
>     displayed summary title and to delete comments   
>
> * Does not seem to support HTML in comments, but you can type 
>    a working URL in "as is".   
>   
You can also link to other bugs using issue:123

> * It can't as far as I can see be locked out to users (unless deleting
>     all the templates would do it), but users would have to get a 
>     Google Account first. It may become more open to abuse as more
>     download traffic goes to Google. 
>   
Ah.  I thought I had locked it down to just people who are part of the 
project.  There are options in each of the templates for that.
> * It offers integration with Subversion (though no current use to us)
>
> * No way of producing release notes from it that I can see (Richard 
>    mentioned the Bugzilla reporting extension for Wiki)
>   
Nothing ideal for release notes.  We can get a list of bugs marked with 
a particular tag, and we can make up new tags easily.  A query for open 
P2 and P3 issues is also possible.  I suspect though that with any 
existing bug tracker we will want to customise the release notes report 
so much that we'll always be using the query only as a guide to what 
bugs we want to describe, which we then cut and paste into wiki to edit.
> Given some people's dislike of the current length of the Checklist
> page, and the many lesser issues that could potentially be added to 
> it, I'm still figuring a move to a tracker could be good, and that I'd
> find it less intimidating to add issues rather than storing them all
> locally. Maybe others would prefer it too (no need to add HTML or
> Wiki Markup as now). 
>
> Vaughan mentioned still using Wiki as an adjunct to a bug tracker. 
>   
I could only see that working in something like the way pending feature 
requests does.  i.e. never duplicate an individual bug across bug 
tracker and wiki.
> Well that sort of duplication was one of my arguments against going 
> to a bug tracker. I suppose there is a weak case for a Wiki page if
> it's no more than a discussion page to thrash out "what are P1/P2"
> at important decision-making times. If there are still going to be
> multiple trackers it seems to defeat the point of moving, to my way 
> of thinking. 
>   
+1

> Well that's my 2p for now. Where are we going from here, given 
> Google code has been loaded up?
>   
I'm perfectly happy to load up bugzilla in the same way, if we/you 
decide we should go with it and we install it and configure it.   I'm 
also perfectly happy to stay with wiki.  Either way I'm happy to delete 
the entries in code.google.com/audacity if that looks right to you.  I 
thought it was worth doing the try-out just to have a closer look at 
what it would be like with the google supplied/maintained issue tracker 
(and maybe to move things on with issue trackers at a faster pace).

If you decide you want us to go with code.google issue tracker, I'll 
enter bugs down to P5 and the 'Fix' bugs of the not-aiming-to page as P5 
New (rather than , P5 Accepted) to indicate we still need to decide what 
priority to give them.

--James.