Forum OpenACS Q&A: Re: upgrade (was: having problems. Refrain from using it until Sept 25th)

I don't know where to even begin optimizing a query like that! But I do believe is the biggest bug database to be used with bugtracker, so it should improve the package if we can fix it.
Posted by Malte Sussdorff on
I think the best way would be to rewrite the beast using the categories package now, but I'm not sure. Furthermore, this would require a thorough rewrite, and I'm not even sure this is useful. Not to mention the hell of an upgrade script.

As I'm not able to tune bug-tracker, we have a couple of options:

a) Delay the upgrade til someone tuned bug-tracker
b) Upgrade but leave bugtracker on the old

Last but not least, a maybe heretic question: How about tanking bug-tracker altogether for and make use of sourceforge (for the bug-tracking)?

Though the last approach would mean we are not eating our own s*** anymore, it has a couple of advantages:

1) We could finally upgrade
2) OpenACS would get great exposure on sourceforge

Posted by Malte Sussdorff on
Some more thinking behind my reasoning for the rewrite using categories, but probably Dave is right and we will see no performance gain.

Bug tracker contains a lot of code to handle categories in a hierarchical manner, if we'd use category system, we could just reuse the functions written therein. Furthermore, it would be a good reason to integrate categories with listbuilder (unless it is already done), meaning, you can map multiple category trees to a package and the listbuilder would display them automatically like the bug-tracker currently does manually.

Last but not least, it would allow us to use multiple categories within one tree, something that would break the current bug-tracker. Useful if a bug e.g. belongs to more than one package.