[Python-Dev] New bugtracker project
Thu, 23 May 2002 09:40:15 -0700
> >>2) an 'efficient' UI. The bugzilla default search results pages are
> >>very inefficient from a UI point of view. Andy McKay's version is much
> >>better, I think.
> >I don't see the difference in the two, aside from a smaller font? The UI
> >for roundup's pretty much completely flexible.
> My only point is that flexibility is fine, but getting the details right
> is what matters in the end. Bugzilla's UI is flexible (it's all Perl,
> after all), but the defaults suck.
Bugzilla 2.16 now features (at last) seperately templated HTML, I haven't
looked into it in any detail though. Most of the changes I made to the
Bugzilla interface for ActiveState were cleaning up: making things clearer
and more useable, in a few cases that meant removing little bits of
Many of the other changes are internal to ActiveState: email integration
(similar to Roundup), bug privacy, workflow changes. Apart from the code
which in some places in terrible (and classic argument against Perl), my only
real complaint about Bugzilla is the UI.
> >Ok. The way we have roundup configured is that a message is sent to
> >a set of users when an issue is opened, and then to users that are
> >"interested" subsequently - they've either commented on the bug, or
> >added themselves to the nosy list. What did you find meant too much
> >email? The "initial email out" was something we added.
> Yeah, we added the same thing. As I said, I forget the details of the
There were many, one was there was no real list of users (see point below),
so you had no idea who should be getting email and it was easy to enter
addresses incorrectly. The idea of roles on a bug (owner, reporter, QA etc)
in Bugzilla and configuring how many emails you get is a good thing.
My other major problem with the old Roundup (not the new one) and Jitterbug
was a lack of clear data definitions. Since Bugzilla has a RDB back end, it
has a well defined set of data, Roundup just stored stuff in text files and
there was little data integrity. I remember there being about 10 different
spellings of one category...
Whatever you guys decide I would recommend caution before starting to
move bug databases. Maintaining the integrity of the data on old bugs as you
move from the SF bug tracker to another can be a pain. If you find you dont
like that new bug tracker and move to another... well that wont be fun.