[Python-Dev] New bugtracker project

[Anthony Baxter]

>>> David Ascher wrote
> 0) keywords -- massively useful for targeting, filtering, etc.

Yes, but not in either of the standard templates.

> 1) Attachments on bugs (somewhat of  a merge of the patch tracker and 
> bug tracker, but also useful for attaching test cases, screenshots, etc.)

Yes. It's also possible to add "state" to an attachment (ala 
bugzilla.mozilla.org). Can submit attachements via email.

> 2) Being able to "watch" people - be notified when their bugs have 
> events happen to them, e.g.. when they're on vacation.

You could install a simple reactor to say "when a nosy event happens for
this user, also add that user to the nosy list."

> 3) Saving and recalling searches

This has been my #1 requested feature to Richard for some time. I'd ask
him again, but I think he's sick of the nagging. :)

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

> 5) scalability (in # of developers, # of users, # of bugs, # of 
> 'versions', # of 'products', etc.)

Unknown.

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

> 7) Bug linkages (depends on/blocks, duplicate handling, etc.)

It's on the "to be done" feature list, looking for someone to do the
work.

> Useful things we've added to bugzilla include:
> 1) Ability to designate bugs as 'for internal use only' (not especially 
> important for python-dev =)

This is something that's being worked on at the moment.

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

> As I've mentioned in the past, we used an earlier version of roundup and 
> found it didn't scale well with thousands of users. 

This was based on ping's initial prototype? The current roundup.sf.net
project is a completely different thing, developed from scratch, and 
initially on the SC spec.

> I haven't look at 
> the new roundup to know if it's dealt with the problems we had 
> (way too much mail generation by default, 

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.

> much too brittle, 

Can't say I've seen that with the current version.

> and poorly 
> architected =).

Would need more details for this.

> It's also important to have flexibility in handling the bug cycle (who 
> closes, who verifies, etc.).  Both roundup and bugzilla did that pretty 
> well.

Yep.

Anthony
-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.