Audacity › audacity-devel

Does Bugzilla still have a case?

45 messages

1 2 3

Gale (Audacity Team)

Does Bugzilla still have a case?

Reply Threaded

A quick note about "Checklist" versus "formal bug trackers".

Apart from lack of time/energy, one reason I haven't laced the
Checklist with a lot of P4/5 "issues" is that it might make it
very hard to read, unless we really had a one line entry for each
of them (sometimes we don't have a thread we can link to which
has an explanation).

Obviously it's possible to have a separate Wiki page for things not
regarded as "bugs", and for P4/5 "issues", but I retain my fear
that hiving those off means they will be forever forgotten. While
Bugzilla allows separate display of "bugs" or "defects", "feature
requests" or "enhancements" are definitely part of its scheme.

While Wiki has some advantages over Bugzilla (easy to change
bug descriptions and remove/merge comments), I'm beginning
to think without Wiki automation of the kind James has suggested:
http://wiki.audacityteam.org/index.php?title=The_Ideal_Bugtracker

we're just going to be too circumscribed if we really want to track
the number of issues we now seem to. Does Bugzilla still have a
case (locked out to the general public)?

Yes we could have sortable tables on the Wiki now (if descriptions
were minimal). But is there any known way of implementing the sort
of Wiki functionality James mentions after 2.0?

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Markus Meyer

Re: Does Bugzilla still have a case?

Reply Threaded

Gale,

having worked with "professional" bug tracking systems at various
commercial projects I think that having a "real" bug tracker is
essential for software project management. Actually, most important open
source projects seem to use a bug tracking system. It need not be
Bugzilla; at work we use Mantis which works well although I do have a
few minor issues with it.

I also think that entering bugs should be allowed to anyone (after
account registration). We can still have a note somewhere that the bug
tracker is not to be used for help requests. And if someone really
enters a bug on a trivial issue we can always just close the bug.

Markus

[hidden email] schrieb:

> A quick note about "Checklist" versus "formal bug trackers".
>
> Apart from lack of time/energy, one reason I haven't laced the
> Checklist with a lot of P4/5 "issues" is that it might make it
> very hard to read, unless we really had a one line entry for each
> of them (sometimes we don't have a thread we can link to which
> has an explanation).
>
> Obviously it's possible to have a separate Wiki page for things not
> regarded as "bugs", and for P4/5 "issues", but I retain my fear
> that hiving those off means they will be forever forgotten. While
> Bugzilla allows separate display of "bugs" or "defects", "feature
> requests" or "enhancements" are definitely part of its scheme.
>
> While Wiki has some advantages over Bugzilla (easy to change
> bug descriptions and remove/merge comments), I'm beginning
> to think without Wiki automation of the kind James has suggested:
> http://wiki.audacityteam.org/index.php?title=The_Ideal_Bugtracker
>
> we're just going to be too circumscribed if we really want to track
> the number of issues we now seem to. Does Bugzilla still have a
> case (locked out to the general public)?
>
> Yes we could have sortable tables on the Wiki now (if descriptions
> were minimal). But is there any known way of implementing the sort
> of Wiki functionality James mentions after 2.0?
>
>
>
> Gale
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Does Bugzilla still have a case?

Reply Threaded

| From Markus Meyer <[hidden email]>
| Wed, 23 Sep 2009 08:48:06 +0200
| Subject: [Audacity-devel] Does Bugzilla still have a case?
> having worked with "professional" bug tracking systems at various
> commercial projects I think that having a "real" bug tracker is
> essential for software project management. Actually, most important open
> source projects seem to use a bug tracking system. It need not be
> Bugzilla; at work we use Mantis which works well although I do have a
> few minor issues with it.

Well I don't mind long Wiki pages at all, but some of us clearly do.
So to keep page size down with lots of issues being tracked, it
seems to me that means breaking the picture up into too many
pages to be useful. I suppose it "could" be made to work with a
Wiki issue tracker "index page":

P1
P2
P3 Bugs
P3 Enhancements
P4 Bugs
P4 Enhancements
P5 Bugs
P5 Enhancements

or something like that, but a logistical nightmare?

Do the professional trackers also handle generation of "bugs fixed"
for Release Notes?

> I also think that entering bugs should be allowed to anyone (after
> account registration). We can still have a note somewhere that the bug
> tracker is not to be used for help requests. And if someone really
> enters a bug on a trivial issue we can always just close the bug.

I wouldn't agree with you there. I think vetting of "bugs" by having
people e-mail feedback@ works better. While some knowledgeable
people might well be able to use a bug tracker to enter good reports
I think they would be in the minority (and experience with our old
Bugzilla with user-entered issues doesn't fill me with confidence).

Thanks

Gale

> > A quick note about "Checklist" versus "formal bug trackers".
> >
> > Apart from lack of time/energy, one reason I haven't laced the
> > Checklist with a lot of P4/5 "issues" is that it might make it
> > very hard to read, unless we really had a one line entry for each
> > of them (sometimes we don't have a thread we can link to which
> > has an explanation).
> >
> > Obviously it's possible to have a separate Wiki page for things not
> > regarded as "bugs", and for P4/5 "issues", but I retain my fear
> > that hiving those off means they will be forever forgotten. While
> > Bugzilla allows separate display of "bugs" or "defects", "feature
> > requests" or "enhancements" are definitely part of its scheme.
> >
> > While Wiki has some advantages over Bugzilla (easy to change
> > bug descriptions and remove/merge comments), I'm beginning
> > to think without Wiki automation of the kind James has suggested:
> > http://wiki.audacityteam.org/index.php?title=The_Ideal_Bugtracker
> >
> > we're just going to be too circumscribed if we really want to track
> > the number of issues we now seem to. Does Bugzilla still have a
> > case (locked out to the general public)?
> >
> > Yes we could have sortable tables on the Wiki now (if descriptions
> > were minimal). But is there any known way of implementing the sort
> > of Wiki functionality James mentions after 2.0?
> >
> >
> >
> > Gale

Markus Meyer

Re: Does Bugzilla still have a case?

Reply Threaded

Gale Andrews schrieb:
>> I also think that entering bugs should be allowed to anyone (after
>> account registration).
> I wouldn't agree with you there. I think vetting of "bugs" by having
> people e-mail feedback@ works better. While some knowledgeable
> people might well be able to use a bug tracker to enter good reports
> I think they would be in the minority (and experience with our old
> Bugzilla with user-entered issues doesn't fill me with confidence).

Now "allowed to anyone" does not mean "should be done by everyone".
People may still choose to email feedback@, in this case bugs will still
be entered by support staff. I'm just saying people should be able to
enter bugs if they want to.

Markus

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Does Bugzilla still have a case?

Reply Threaded

| From Markus Meyer <[hidden email]>
| Wed, 23 Sep 2009 20:41:04 +0200
| Subject: [Audacity-devel] Does Bugzilla still have a case?

> Gale Andrews schrieb:
> >> I also think that entering bugs should be allowed to anyone (after
> >> account registration).
> > I wouldn't agree with you there. I think vetting of "bugs" by having
> > people e-mail feedback@ works better. While some knowledgeable
> > people might well be able to use a bug tracker to enter good reports
> > I think they would be in the minority (and experience with our old
> > Bugzilla with user-entered issues doesn't fill me with confidence).
>
> Now "allowed to anyone" does not mean "should be done by everyone".
> People may still choose to email feedback@, in this case bugs will still
> be entered by support staff. I'm just saying people should be able to
> enter bugs if they want to.
>
>
> Markus

Then (although this is all hypothetical) I would say people who
want to add bugs via the bug tracker should be vetted (perhaps
have to apply for an account in the same way accounts on the
Manual Wiki are vetted).

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Gale (Audacity Team)

Gale,

Yes, Bugzilla still has a case. If you want to move to Bugzilla, then I
would be fine with that. It is after all you who does most of the work
on organizing the bugs - and we're more a do-ocracy than a democracy.
In many ways it is your decision. How we track bugs probably has more
impact on your workload than on anyone else's. I think it would cost
you a bit more time in updating bugs if we went the Bugzilla way, and I
don't think it would actually help with keeping low priority bugs
visible, which I understood to be your main reason. However, it would
make us look more professional, and we would be able to create more
kinds of report. I would help with transferring bugs. I agree about
not allowing open access for bug reporting - based on past experience.

If we went with Bugzilla we would probably also want to use the
media-wiki Bugzilla extension which allows us to embed Bugzilla reports
and links into media-wiki pages. I would not be keen to move feature
requests to Bugzilla, at least not yet. I think they are working
sufficiently well (with your and Pete's supervision) with what we now
have on the wiki.

We would want to consider in some detail how to customise it. I use
Bugzilla at work. At work it is a close to default configuration, with
loads of fields that are just irrelevant to my workplaces way of
working.and to ours in Audacity too.

By our choice of set up we could have a field for 'release notes', and
we could introduce the concept of heisenbugs and a field to indicate
'this is a regression'. We'd lose some of the good wiki-esqueness, but
could use it our own way. Yes, we could have a Bugzilla release-note
report that did a good enough job of showing what is still broken and
what has been fixed.

------

Any possibility of 'the ideal bug tracker'?

Possible. We could put work in to making Melange (google's GSoC/GHOP
application) work that way. GHOP has a built in issue tracker. We'd
get tremendous goodwill from Google Open Source Office for helping
improve Melange. An additional benefit is that we would be 'GHOP
ready'. Moving our issues over, we'd have real issues ready in GHOP
format. No mistake, there would be a very significant time cost for us
in doing all this. Pretty much it only makes sense if we are very
serious indeed about wanting to do GHOP in 2010.

Much as I'd love the second approach to happen, I don't think we have
the resources to do both GHOP and GSoC in 2010 and that therefore it
would be bad for us. If we've got too many bugs for wiki and really do
need to move from it, then bugzilla is likely the way forward.

--James.

Gale Andrews wrote:

> | From Markus Meyer <[hidden email]>
> | Wed, 23 Sep 2009 08:48:06 +0200
> | Subject: [Audacity-devel] Does Bugzilla still have a case?
>
>> having worked with "professional" bug tracking systems at various
>> commercial projects I think that having a "real" bug tracker is
>> essential for software project management. Actually, most important open
>> source projects seem to use a bug tracking system. It need not be
>> Bugzilla; at work we use Mantis which works well although I do have a
>> few minor issues with it.
>>
>
> Well I don't mind long Wiki pages at all, but some of us clearly do.
> So to keep page size down with lots of issues being tracked, it
> seems to me that means breaking the picture up into too many
> pages to be useful. I suppose it "could" be made to work with a
> Wiki issue tracker "index page":
>
> P1
> P2
> P3 Bugs
> P3 Enhancements
> P4 Bugs
> P4 Enhancements
> P5 Bugs
> P5 Enhancements
>
> or something like that, but a logistical nightmare?
>
> Do the professional trackers also handle generation of "bugs fixed"
> for Release Notes?
>
>
>
>> I also think that entering bugs should be allowed to anyone (after
>> account registration). We can still have a note somewhere that the bug
>> tracker is not to be used for help requests. And if someone really
>> enters a bug on a trivial issue we can always just close the bug.
>>
>
> I wouldn't agree with you there. I think vetting of "bugs" by having
> people e-mail feedback@ works better. While some knowledgeable
> people might well be able to use a bug tracker to enter good reports
> I think they would be in the minority (and experience with our old
> Bugzilla with user-entered issues doesn't fill me with confidence).
>
>
> Thanks
>
>
> Gale
>
>
>
>
>>> A quick note about "Checklist" versus "formal bug trackers".
>>>
>>> Apart from lack of time/energy, one reason I haven't laced the
>>> Checklist with a lot of P4/5 "issues" is that it might make it
>>> very hard to read, unless we really had a one line entry for each
>>> of them (sometimes we don't have a thread we can link to which
>>> has an explanation).
>>>
>>> Obviously it's possible to have a separate Wiki page for things not
>>> regarded as "bugs", and for P4/5 "issues", but I retain my fear
>>> that hiving those off means they will be forever forgotten. While
>>> Bugzilla allows separate display of "bugs" or "defects", "feature
>>> requests" or "enhancements" are definitely part of its scheme.
>>>
>>> While Wiki has some advantages over Bugzilla (easy to change
>>> bug descriptions and remove/merge comments), I'm beginning
>>> to think without Wiki automation of the kind James has suggested:
>>> http://wiki.audacityteam.org/index.php?title=The_Ideal_Bugtracker
>>>
>>> we're just going to be too circumscribed if we really want to track
>>> the number of issues we now seem to. Does Bugzilla still have a
>>> case (locked out to the general public)?
>>>
>>> Yes we could have sortable tables on the Wiki now (if descriptions
>>> were minimal). But is there any known way of implementing the sort
>>> of Wiki functionality James mentions after 2.0?
>>>
>>>
>>>
>>> Gale
>>>

Benjamin Drung-2

Re: Does Bugzilla still have a case?

Reply Threaded

Hi,

I appreciate the suggestion to use a bug tracker. I do not like the
current process. It's not transparent to me and I do not know, if the
bugs are already reported.

I have touched many bug tracking system among others Bugzilla. IMO it is
complex, slow and does not make fun. The bug tracker of Sourceforge is
even worse. There is only one tracker I like: Launchpad (and no, it's
not because I am a Ubuntu user)

There is already a project created for audacity:
https://launchpad.net/audacity

Some advantages:

* it's simple
* there is a answer tracker, too (you can convert bugs into question and
the other way round)
* you can use tags to group them (you can also use milestones)
* you can link to other bug tracker (e.g. if they are reported in other
distributions like Debian, Fedora, Ubuntu, etc.)

What do you think? Would you give Launchpad a try?

Cheers,
Benjamin

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Vaughan Johnson

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Gale (Audacity Team)

I agree with most of what The_Ideal_Bugtracker says about inadequacies
of bug trackers, and other comments on this thread, but I reiterate my
+1 on them over plain wiki (or using wiki in conjunction). Thanks for
revisiting it Gale.

- V

[hidden email] wrote:

Benjamin Drung-2

Re: Does Bugzilla still have a case?

Reply Threaded

One complain there is not valid for Launchpad:

"Bug trackers waste time: As the bug list gets longer, so do the bug
reports - and so do the bug review meetings. From an efficiency
perspective, that's a Sclemiel The Painter's Procedure. There is no
summarisation. Work to do to review bugs grows worse than linearly.
Eventually that weekly bug review meeting has to be abandoned. No one
has the stamina to do it all in one sitting. It's an unsatisfying
meeting too. It keeps degenerating into trivia - often the same 'push my
button' topics. The bug trackers discourage changing of the bug title to
focus on the current (remaining) problems, because doing so can seem to
make a nonsense of the audit trail."

In Launchpad the initial report is the bug description. You can update
this description and do not have to dig through the comments then.

Am Mittwoch, den 23.09.2009, 14:25 -0700 schrieb Vaughan Johnson:

> I agree with most of what The_Ideal_Bugtracker says about inadequacies
> of bug trackers, and other comments on this thread, but I reiterate my
> +1 on them over plain wiki (or using wiki in conjunction). Thanks for
> revisiting it Gale.
>
> - V
>
> [hidden email] wrote:
> > A quick note about "Checklist" versus "formal bug trackers".
> >
> > Apart from lack of time/energy, one reason I haven't laced the
> > Checklist with a lot of P4/5 "issues" is that it might make it
> > very hard to read, unless we really had a one line entry for each
> > of them (sometimes we don't have a thread we can link to which
> > has an explanation).
> >
> > Obviously it's possible to have a separate Wiki page for things not
> > regarded as "bugs", and for P4/5 "issues", but I retain my fear
> > that hiving those off means they will be forever forgotten. While
> > Bugzilla allows separate display of "bugs" or "defects", "feature
> > requests" or "enhancements" are definitely part of its scheme.
> >
> > While Wiki has some advantages over Bugzilla (easy to change
> > bug descriptions and remove/merge comments), I'm beginning
> > to think without Wiki automation of the kind James has suggested:
> > http://wiki.audacityteam.org/index.php?title=The_Ideal_Bugtracker
> >
> > we're just going to be too circumscribed if we really want to track
> > the number of issues we now seem to. Does Bugzilla still have a
> > case (locked out to the general public)?
> >
> > Yes we could have sortable tables on the Wiki now (if descriptions
> > were minimal). But is there any known way of implementing the sort
> > of Wiki functionality James mentions after 2.0?
> >
> >
> >
> > Gale
> >
> >
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Vaughan Johnson

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Vaughan Johnson

I meant +1 on using bugtracker + wiki adjunct (to try to cover some of
those inadequacies).

Vaughan Johnson wrote:

> I agree with most of what The_Ideal_Bugtracker says about
> inadequacies of bug trackers, and other comments on this thread, but I
> reiterate my +1 on them over plain wiki (or using wiki in
> conjunction). Thanks for revisiting it Gale.
>
> - V
>
> [hidden email] wrote:
>> A quick note about "Checklist" versus "formal bug trackers".
>> Apart from lack of time/energy, one reason I haven't laced the
>> Checklist with a lot of P4/5 "issues" is that it might make it very
>> hard to read, unless we really had a one line entry for each
>> of them (sometimes we don't have a thread we can link to which has an
>> explanation).
>> Obviously it's possible to have a separate Wiki page for things not
>> regarded as "bugs", and for P4/5 "issues", but I retain my fear that
>> hiving those off means they will be forever forgotten. While Bugzilla
>> allows separate display of "bugs" or "defects", "feature requests" or
>> "enhancements" are definitely part of its scheme.
>> While Wiki has some advantages over Bugzilla (easy to change bug
>> descriptions and remove/merge comments), I'm beginning to think
>> without Wiki automation of the kind James has suggested:
>> http://wiki.audacityteam.org/index.php?title=The_Ideal_Bugtracker
>>
>> we're just going to be too circumscribed if we really want to track
>> the number of issues we now seem to. Does Bugzilla still have a case
>> (locked out to the general public)?
>>
>> Yes we could have sortable tables on the Wiki now (if descriptions
>> were minimal). But is there any known way of implementing the sort
>> of Wiki functionality James mentions after 2.0?
>>
>>
>>
>> Gale
>>
>

Richard Ash (audacity-help)

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by James Crook

On Wed, 2009-09-23 at 21:34 +0100, James Crook wrote:
> We would want to consider in some detail how to customise it. I use
> Bugzilla at work. At work it is a close to default configuration, with
> loads of fields that are just irrelevant to my workplaces way of
> working.and to ours in Audacity too.
Definitely agree with this. We could remove a lot of things we won't
use, and re-purpose some others. Setting up the defaults for new bugs is
also important, so that noise is easy to filter out.

This would be very helpful to distribution package maintainers and other
"downstream" developers, because they have a fixed URL to link back to
for an issue, and can get notified automatically when it makes progress.

http://bugs.gentoo.org is another example, with fairly heavy
customisation (including integration which matches packages to known
upstream contacts, so any bugs opened against Audacity should get me in
the CC field and I know about them). We wouldn't need to get that far,
but we can create custom status and resolution entries to address some
of the things which can't be expressed in "vanilla" bugzilla.

The mediawiki extension for reporting looks very promising, and
considerably better as a way of holding report queries than the very
long custom URLs which express the same search.

We then have a choice in that we can either use explicit milestones to
decide bug priority, or the priority field (I suspect we don't want to
do both). I would also point out that by using bug dependencies quite a
lot of powerful grouping / sub-bug behaviour can be obtained although
there isn't a dedicated UI for the purpose (once a bug depends on
another, you can't close the parent until the dependent bugs are
(separately) closed).

Bugzilla benefits significantly from a reasonably powerful webhost, and
feels awful on a grinding slow one (mainly CPU / memory, because it
usually ends up running CGI-BIN perl), but that shouldn't be a problem
for us now we have our own server to host it. This to some extent
mitigates the fact that you have to change each bug independently,
unless you create a search which returns exactly the right bugs, then
make the change on all those bugs in one go from the search result.
Given you can add specific bugs to a nominated (stored) search, you can
build up a list of random bugs to alter, as well as things like "change
all bugs in themeing to be low priority".

I'd be interested in seeing what we could achieve by customising
bugzilla 3.4 - it think it's come quite a long way since the 2.2.
releases I last seriously used.

Richard

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: Does Bugzilla still have a case?

Reply Threaded

> On Wed, 2009-09-23 at 21:34 +0100, James Crook wrote:
> > We would want to consider in some detail how to customise it. I use
> > Bugzilla at work. At work it is a close to default configuration, with
> > loads of fields that are just irrelevant to my workplaces way of
> > working.and to ours in Audacity too.

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

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

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

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

Well that's my 2p for now. Where are we going from here, given
Google code has been loaded up?

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Richard Ash (audacity-help)

Re: Does Bugzilla still have a case?

Reply Threaded

On Mon, 2009-09-28 at 10:05 +0100, Gale Andrews wrote:

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

Whilst I can see the point of making "everything a label" I suspect in
this case it will actually not be a good idea, because it makes it much
harder to ensure that the correct labels are on each report. I'm also
concerned that even the advanced search isn't much compared to
Bugzilla's advanced search (notably, if I want to search for a given
value, I generally have to type that in a free-text field, not choose it
from a list), and you can't save searches (which is where the power of
most of the Bugzilla extensions come from) to re-generate results in the
future (i.e. re-run the query again in the future).

> 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).
It is easy to open a report, and with sensible classification, a long
total list needn't be a problem (Gentoo has 286000 bugs, 5000 open (if I
believe the query I've just done)), provided that we have ways to
partition it - I think breaking audacity down into components (including
a "parking" one which is default for everything on bug entry) as James
has started to do is critical.

> Vaughan mentioned still using Wiki as an adjunct to a bug tracker.
> 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.

I agree we won't want a wiki page for most bugs, but we shouldn't be
afraid to make the URL field of a bug point out to a wiki page.
Especially, we should aim to have useful reports on the wiki via the
extension, so that the equivalent of the current release checklist is a
bugzilla query page with the selected bugs on it. Crucially, unlike a
plain bugzilla saved search, it is then visible to everyone, rather than
being personal. Personal saved searches are very handy though, e.g. "All
open Linux bugs" affects me, but not many others. Once we have
components, there will be more possible searches as well.

I'm out tomorrow night, but unexpectedly will be in on Thursday, so I
might try and customise a local bugzilla install then, which should be
easy enough to later transfer to a server for people to play with (but I
suspect it will be easier to play with customising it locally, and I can
install bugzilla via my package manager).

Richard

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Richard Ash (audacity-help)

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Benjamin Drung-2

On Wed, 2009-09-23 at 23:34 +0200, Benjamin Drung wrote:
> "Bug trackers waste time: As the bug list gets longer, so do the bug
> reports - and so do the bug review meetings. From an efficiency
> perspective, that's a Sclemiel The Painter's Procedure. There is no
> summarisation.

That depends on how you set bugzilla's permissions, because the Summary
should be editable, what this says is that we should allow anyone who
can change the bug to also change the summary. Encouraging starting new
bugs not extending existing ones also helps, because the new bug can
have a new summary (what is shown in the search tables).

Richard

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Richard Ash (audacity-help)

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Gale (Audacity Team)

On Mon, 2009-09-28 at 10:05 +0100, Gale Andrews wrote:
> Hi James
> I noticed you added all the P2s and P3s to the GoogleCode Issue Tracker
> (without thread links).

There is a potential issue with starting to use the wiki on Google Code
before we migrate source code into Subversion there, which is that wiki
pages end up in the Subversion repository, so we will have to extract
the repository, merge the two, and then get the repository re-set so we
can re-upload the merged repository. It's not impossible, but we may
need to get admin help if we are trying to do it having made a
significant number of commits to the repository (I think I saw a FAQ to
this intent).

Richard

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Gale (Audacity Team)

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.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Richard Ash (audacity-help)

I have been reading these discussions but not contributing, as I know
little of bugzilla, http://code.google.com/p/audacity/wiki/BugLists
etc.. However, as a 'user' (developer/bug fixer) and looking for bugs
to fix (and wishing to know of progress on them), I looked at
http://code.google.com/p/audacity/wiki/BugLists and saw a good way of
sorting them in different ways, quickly and easily (thanks James for
temporarily populating that). Much better than the current wiki method.

It's something that needs a database solution, not a long (marked-up)
text solution.

Just my 2p.
Martyn

Richard Ash wrote:

> On Wed, 2009-09-23 at 23:34 +0200, Benjamin Drung wrote:
>> "Bug trackers waste time: As the bug list gets longer, so do the bug
>> reports - and so do the bug review meetings. From an efficiency
>> perspective, that's a Sclemiel The Painter's Procedure. There is no
>> summarisation.
>
> That depends on how you set bugzilla's permissions, because the Summary
> should be editable, what this says is that we should allow anyone who
> can change the bug to also change the summary. Encouraging starting new
> bugs not extending existing ones also helps, because the new bug can
> have a new summary (what is shown in the search tables).
>
> Richard
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

James Crook

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by Richard Ash (audacity-help)

It can be argued that it isn't the bug tracker design so much as how
people use them that is the problem. Being able to change the title is
essential..

For our Bugzilla set up I would like us to have (at least):

* A title - Short. Just enough text to identify the issue (for someone
already generally familiar with the bug list) E.g "Label linking
broken in truncate silence"
* A summary - Enough text so that I know the current status in some
detail, e.g. that it has been fixed (and works) for single mono tracks
and that there is still some discussion as to what the underlying
truncate silence effect should do for multiple tracks and stereo
tracks. A summary, not the full audit trail.
* Release note text - Possibly blank, but if we're expecting to release
with this bug then the exact text that we'd want in a release that had
this bug in it.

The summary is additional to the comment/audit trail and is kept up to
date as work is done on bugs and the issues become clearer.

I'd like us to try to keep feature requests out of the issue tracker -
at least initially - so that the issue tracker really does focus on bugs.

--James.

.

Richard Ash wrote:

> On Wed, 2009-09-23 at 23:34 +0200, Benjamin Drung wrote:
>
>> "Bug trackers waste time: As the bug list gets longer, so do the bug
>> reports - and so do the bug review meetings. From an efficiency
>> perspective, that's a Sclemiel The Painter's Procedure. There is no
>> summarisation.
>>
>
> That depends on how you set bugzilla's permissions, because the Summary
> should be editable, what this says is that we should allow anyone who
> can change the bug to also change the summary. Encouraging starting new
> bugs not extending existing ones also helps, because the new bug can
> have a new summary (what is shown in the search tables).
>
> Richard
>

Ed Musgrove

Re: Does Bugzilla still have a case?

Reply Threaded

Some javascript/style in this post has been disabled (why?)

The following 3 paragraphs are a paraphrased excerpt from a post I made a few years ago on a forum dedicated to beta testers of DesignCAD.

There must be a formal bug report form available on an (open??) forum. This form should have a place to attach the output of menu File->Export… from “System Info” (msinfo32.exe--I am only vaguely familiar with Windows XP and Vista, I hope other OSs on which Audacity runs have something similar.) It should guide the reporter through the steps of creating a useful (to the programmers) bug report—system details (hardware and software), what the precise steps are to create the bug, exactly what the bug is (what the program does vs. what the tester expects), is it a bug in the program vs. error in the documentation etc..

There must be an accessible bug database (mostly read only, some fields write-append—a small set of the developers will maintain this) with a link to the forum so that the bug reporter can update (i.e. append to) the bug details as needed and everyone can discuss the bug (i.e. add additional information which the database maintainers may add to the bug details). The database must have fields for the obvious things like reporter’s name or forum ID, contact information for the reporter (e-mail @dress), date, details etc.. It also needs a field for status (feature request, unconfirmed, confirmed, resolved, not a bug—intended feature), this will be originally assigned by the database maintainers who will update it as needed. It needs (hidden to the general users) fields for things like assigned programmer(s), and programmer’s current estimate of time to fix.

There needs to be a password protected online site with database access and a discussion forum where users may post (programmers are strongly encouraged to at least lurk and preferably post). Screenshots and Audacity’s saved projects must be attachable on the forum with a field in the database to record links to them.

Here is an example from a bug report form I designed for this commercial software company with a specific bug I submitted (see note below on implementation):

TITLE:

New File Wizard bug

SHORT DESCRIPTION:

"OK" button graphically displayed as "active button" (i.e. <ENTER> key will instigate its action), but <ENTER> key does not have any affect.

SEVERITY:

Broken user interface

VERSION FIRST EXHIBITING BUG:

18.0

MOST RECENT VERSION EXHIBITING BUG:

18.1betaReleaseCandidate

LONG DESCRIPTION:

In 15.3, double-clicking on the desktop icon opens DCad with the "New File Wizard..." dialog open, the "Open an existing drawing" icon selected, the top file in the "Select from a file list" listbox highlighted, and the "OK" button active (i.e. the button who's action will be taken if the <ENTER> or <CR> key is pressed). If (assuming I have files in the list and one is selected) I simply press the <ENTER> key, the last file I worked on opens--cool and SOP.

In 18.0-18.1bRC everything is visually the same--it looks like pressing <ENTER> will open the last file I worked on; but, pressing either the keypad <ENTER> or the keyboard <ENTER> results in no action (clicking the "OK" button with the mouse does have the expected result of opening the file).

PICTURE(s):

http://... [There was a link to a picture on the forum here.]

HARDWARE and SOFTWARE CONFIGURATION:

System Information report written at: 09/19/09 09:14:33

System Name: ARMOR

[System Summary]

Item Value

OS Name Microsoft® Windows Vista™ Ultimate

Version 6.0.6002 Service Pack 2 Build 6002

Other OS Description Not Available

OS Manufacturer Microsoft Corporation

System Name ARMOR

System Manufacturer System manufacturer

System Model P5E3 Deluxe

System Type x64-based PC

Processor Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz, 2997 Mhz, 2 Core(s), 2 Logical Processor(s)

BIOS Version/Date American Megatrends Inc. 1412, 4/13/2009

SMBIOS Version 2.4

Windows Directory C:\Windows

System Directory C:\Windows\system32

Boot Device \Device\HarddiskVolume2

Locale United States

Hardware Abstraction Layer Version = "6.0.6002.18005"

User Name Armor\Edgar

Time Zone Pacific Daylight Time

Installed Physical Memory (RAM) 8.00 GB

Total Physical Memory 8.00 GB

Available Physical Memory 5.76 GB

Total Virtual Memory 7.75 GB

Available Virtual Memory 5.54 GB

Page File Space 0 bytes

[... huge amount of information deleted—can be supplied upon request]

Attachments:

none

Note: I did not design an HTML form for this, I created a template message on the forum which had the headings but no bug details (the beta testers where all fairly sophisticated and capable of dealing with this; for Audacity's purposes I would suggest someone creates an HTML form). Bug reporters opened that message and copied it then opened a new message and paste it in the template. When the database maintainer transferred the bug report from the forum to the database a formal severity was assigned chosen from this list: causes OS to crash, causes app to crash, showstopper (cannot complete project), and annoyance (has a workaround). BTW, I changed the report from “System Info” to reflect today’s information in case anyone was interested in my hardware/software setup!

-Ed Musgrove

Gale (Audacity Team)

Re: Does Bugzilla still have a case?

Reply Threaded

In reply to this post by James Crook

| From James Crook <[hidden email]>
| Tue, 29 Sep 2009 13:29:16 +0100
| Subject: [Audacity-devel] Does Bugzilla still have a case?

>
> It can be argued that it isn't the bug tracker design so much as how
> people use them that is the problem. Being able to change the title is
> essential..
>
> For our Bugzilla set up I would like us to have (at least):
>
> * A title - Short. Just enough text to identify the issue (for someone
> already generally familiar with the bug list) E.g "Label linking
> broken in truncate silence"

Agree in principle, but perhaps someone not actively working
on tracking may be less familiar with the bugs than might be
apparent, especially if we track more of them. I think one
reason I find it easy to skip the explanatory text on the
Checklist is that I'm very familiar with it. Someone who
is less so may find themselves trying to read it all.

> * A summary - Enough text so that I know the current status in some
> detail, e.g. that it has been fixed (and works) for single mono tracks
> and that there is still some discussion as to what the underlying
> truncate silence effect should do for multiple tracks and stereo
> tracks. A summary, not the full audit trail.

Are the steps to reproduce in the first descriptive comment
the bug was opened with? One comment continually made
about the Checklist seemed to be that the steps to reproduce
weren't always there (laid out as 1,2,3). The usual reason
they weren't there like that was reluctance to use the
vertical space needed to present them.

Should the steps to reproduce be clearly findable as their
own section, even separate from comments?

> * Release note text - Possibly blank, but if we're expecting to release
> with this bug then the exact text that we'd want in a release that had
> this bug in it.

User-oriented, and possibly including "workaround"
information when useful.

> The summary is additional to the comment/audit trail and is kept up to
> date as work is done on bugs and the issues become clearer.

That may actually need quite a bit of self-discipline for
people to do that. If people didn't update the summary,
but the expectation was that they had, it could be
pretty misleading.

> I'd like us to try to keep feature requests out of the issue tracker -
> at least initially - so that the issue tracker really does focus on bugs.

If the tool is worth its salt it must be capable of dealing
with developer-supported enhancements, which is all
we're currently planning to use it for. I need to use it
for those type of enhancements so I can load them
in when they come up and not store them locally as now.

So perhaps this means that the default view does not show
them, but I can choose to do so (separately, or in the
complete list).

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

1 2 3