[Python-Dev] New bugtracker project

[David Ascher]

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.)
>>
>
>Unknown.
>
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 
DB backend.

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

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

--david

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.