[Python-Dev] New bugtracker project

[Andy McKay]

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

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

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.

been-through-the-jitterbug-roundup-bugzilla-pains'ly yours
-- 
  Andy McKay