[Python-Dev] New bugtracker project
Tue, 21 May 2002 23:52:01 -0700
Re: Anthony Baxter's comments:
I am aware that NewRoundup is a brand new beast, and that's a very good
thing. =) As Ping himself noted in his release, roundup wasn't really
architected. We pushed it too hard, and paid the price. I'm quite
confident that the new roundup is much better. I'm also confident that
both the new roundup and bugzilla would be better than the SF tracker =).
The fact that the new roundup is in Python is a huge win IMO compared to
bugzilla -- I can't tweak bugzilla, since my Perl sucks.
>>4) non-web, non-email access to the database (e.g. take all the bugs
>>assigned to so and so, and take those submitted by people in england,
>>and set the keyword "never" to them).
>There's the roundupdb interface, where you can directly script the database.
>This requires local access (unless there's some sort of remote RPC for it).
That's fine by me.
>>5) scalability (in # of developers, # of users, # of bugs, # of
>>'versions', # of 'products', etc.)
The biggest issue I see with roundup there is that the original model at
least tended to generate wayyy too much mail, and the nosy list concept
didn't really work well for long-lived bugs (I didn't really analyze the
deeper 'why', sorry -- maybe Mark's memory is better than mine =).
For one thing, it was basically impossible for people with only a
peripheral view of the database (managers, QA folks) to get accurate
pictures of the database. Nothing that can't be fixed if one has a real
>>6) Being able to migrate a bug from one product to another (not all that
>>relevant for a Python-only bug tracker, except if the versions are
>>handled as different products).
>Assuming we're not just talking about tweaking the metadata, this is an
>export/import task. Done.
Well, it's an export task done on a bug -- and all the metadata goes
along with it, if you see what I mean. It just shows up in a different
set of queries.
>>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.
>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
>Would need more details for this.
No you don't. =) Roundup used the filesystem as a database, and lots
of things didnt' work right in high load situations. I'm confident that
the new one has a much better design.
PS: bugzilla _does_ have a learning curve, not too bad a one for users
w/ some UI cleanup (as in the 'simple search'), but pretty steep if
people want to become power-users. Bugzilla also has a _ton_ of
features, and someone else is worrying about it. I hear that bugzilla
is also not very 'open' as a project -- getting changes back into the
core is hard, and some of the changes that are needed (refactoring to
make the UI more easily configurable, for example, and the email
interface) are hard to get 'in'. This is mostly hearsay though.