On Mon, Apr 9, 2012 at 11:49, Dave Abrahams <dave@boostpro.com> wrote:
The thing that's lost by this idea is any sense of being able to achieve a substantial speedup ASAP without lots of work, experimentation, etc. There's a script to convert Trac to Redmine. If it works and Redmine is fast enough, we're done solving the speedup problem. If not, consider alternatives.
Hi, I dont have an advice on this but I have just 3 infos about that that might be good to take into account : 1. I suspect that the conversion script will make the tickets exactly in the same configuration than in TRAC (obvious so far). Once done, if you want to have one separate (sub) project in Redmine for each boost library, then there is sone "manual" work to do. I m not sure about what the work would be. Best case would be to simply select all tickets that have a component of the name of a specific library and have a way in redmine to move those tickets into a specific sub project for this library. 2. Maybe I m wrong but it looks to me that the Redmine community have been divided during the last year. Some developers didnt agree with the development process and forked the project to make the Chili project ( https://www.chiliproject.org/ ) I dont know what is the impact on the tools but it might be a good idea to have some clues about the stability of the tool project. Or maybe it s not important, anyway now you know about it. Also, Redmine being faster looks true for my experience, BUT the scale of boost project and the fact that a lot of people can access it makes me think that maybe Redmine will be as slow as TRAC for this project with the same hardware ( also Ruby isnt reputed to be fast execution...) so as Dave says I guess the only way to check this is to test it. Hope it helps. Joel Lamotte