Roundup Tracker - Issues

Message4618

Author lu_zero
Recipients ber, lu_zero
Date 2012-08-21.11:32:25
Message-id <503371C3.8080605@gentoo.org>
In-reply-to <1345547624.34.0.0446310910428.issue2550702@psf.upfronthosting.co.za>
On 8/21/12 1:13 PM, Bernhard Reiter wrote:
>
> Bernhard Reiter added the comment:
>
> A good to know!
> I'd be interested in your experiences, e.g. what is "big"
> and "other things". Ideally on the -devel list. :)

Big -> anything bigger than 20-30 would slow to a crawl, we are talking 
about bicubic complexity for nothing. (nested lookup+ string comparison)

> Especially: What would we need to improve to make roundup fit your needs?

1- have a stock setup not requiring to edit TAL to be on par with the 
stock bugzilla
2- have a stock setup not so slow that it is unusable on the same system 
bugzilla (or even trac) can run decently
3- have the wsgi deploy in a canned recipe easy to be followed
4- have a way to import/export to bugzilla xml.

Not something that could be done overnight I guess ^^;

> Which version did you try and which database?

I used the mysql backend but it is completely unrelated to the problem 
at hand.

The database abstraction is/was completely bogus. Something like 
sqlalchemy declarative base probably could replace that faulty component 
with minor disruption. (then I could point that the whole "store the 
messages in the filesystem" requiring a little unsettling)

Chameleon probably would make the web ui work faster even if tal is sort 
of hard to follow compared to genshi or jinja

lu
History
Date User Action Args
2012-08-21 11:32:26lu_zerosetrecipients: + lu_zero, ber
2012-08-21 11:32:26lu_zerolinkissue2550702 messages
2012-08-21 11:32:25lu_zerocreate