> You say that Roundup *was* going to be the item of choice. Are you
> going to replace it with something else?
> I was just about to start using it for all viewer bug reports and
> feature requests, so I would like to know if you are going to replace
> it with something else.
My only beef with it is that it's web-enabled python code, so
every launch will launch the python interpretor on the box. With perl
code, I use mod_perl wrapped into apache, but I haven't yet found a
mod_python or such.
Let's use it anyway, until something weird happens. I rather like
it much more than Bugzilla and Jitterbug.
> Some kind of user-friendly frontend to Roundup for the initial bug
> report would help a lot. One BIG problem with Roundup is that you have
> to give it a correct category on the subject line when sending the bug
> report mail or it will require manually intervention on the server to
> put it in the correct category.
Simple dropdown with limited selections can solve that, or have it
bounced to the user if it doesn't match the array of @categories.
> One thing I added to my own copy of Roundup was a possibility to
> reject a bug report. It's just a matter of adding a new status code in
> bugdb.py and a color (I used red #ff0000) in roundup.py. I would like
> to see something similar in the version on our web site.
Sure, no problems there. But I'm not tying into Spider.py, no
matter how much begging Bill and Chris do >=)
> You'll have to do something about the "Fixer" field, too. When you
> enter a name in that field and save the changes Roundup will try to
> send a mail to that user by adding the first domain in the MAILDOMAINS
> list (roundup_config.py) to the entered name. Maybe you can add
> aliases to map the "local addresses" to the real mail addresses.
I'll take a look. I'd like to also back-end this into mysql, and
not the filesystem, so I can run custom reports/queries on it from another
webpage ("Show me all reports in January which involve Spider.py").
/d
