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@boostpro.com> 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