> >>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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4