Re: [boost] Slow Bugs Tracker

Subject: Re: [boost] Slow Bugs Tracker
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-04-08 19:31:00

Dave Abrahams wrote:
> on Sun Apr 08 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
>
>> AMDG
>>
>> On 04/08/2012 09:55 AM, Olaf van der Spek wrote:
>>> On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave_at_[hidden]>
>>> wrote:
>>>>
>>>> I'm sorry, I thought I already posted this reply but I don't see it
>>>> here.
>>>>
>>>> We've heard from people who say they've never seen a Trac
>>>> installation with good performance.  However...
>>>>
>>>> IMO it will not be productive to go through an extensive analysis
>>>> of the current performance, a review of other issue tracker
>>>> improvement requests, or a survey of other tracker technologies.
>>>> What we need is improved performance, ASAP.  The only way to know
>>>> how Redmine will perform in practice for Boost is to try it.
>>>
>>> Beman,
>>>
>>> Is this ok with the steering committee?
>>>
>>
>> I can't speak for anyone else, but
>> throwing something in and hoping it
>> helps is most certainly not okay with me.
>
> What does "throwing something in" mean?
>
> What better way is there to find out if performance is better than to
> migrate the data and exercise the site?  If you have other
> suggestions, please make them.

Hmm - what does "The only way to know
Redmine will perform in practice for Boost is to try it." mean?

It sounded like what was being proposed was not a test but
rather just moving to something else "ASAP"  I doubt anyone
would object to some real test.  But that's not so easy. I'm
guessing that the performance is subtect to the size of the
database and the configuration.  So to it's hard to make a
real test without migrating the whole trac history to the
"other" system - whatever that might be.   The proposal
sounded like "let's just do it" which is what I believe raised
concerns.

Is it possible that the Trac is slow because of the hardware
configuration it's being run on?  Do we have any control over that?
Note that Source Forge offers to run Trac systems for any
library.  I wonder what the performance would be if it were
run there?

Finally, maybe it's time to give up on the idea of a monolithic
Trac system.  Seems to me that letting each library have it's
own Trac system would be a small first step in the direction
of modularization as well as solving the performance issue.
But then, it wouldn't even be a requirement that each library
use the same Trac system.  And it would be easy to test/experiment
since any authors who are fed up with the current system
could just migrate out to the one they prefer.  So if some idea
turns out to be a bad one, the damage will be limited to one
library to be fixed up by the person who made the change.

As far as I can see, the only thing lost by this idea would
be the ability to easily re-assign tickets. This would be
inconvenient, but seems a small price to pay.  BTW
I don't know this but I'm wonder if ASIO and Spirit
don't already have their own systems for tracking bugs
and enhancements.

Robert Ramey