(Mybe that should be moved in another "thread") About moving from TRAC, I'm not the most experienced here but my personal research about this specific thing (bug tracking tools) came to this : 1. TRAC is at the moment well thought for big libraries (looks like implementors are really experimented and think a lot before coding), better than Redmine that is still young (in my view at least). 2. TRAC will have the major feature everyone ask for in coming releases : multiple projects management. Redmine have it from the start. TRAC schedule is always (very) late so it depends on when you want what. 3. Redmine is really powerful on the user experience side : easier to do anything than TRAC. However, some improvement in TRAC makes me think that some enhancements are going on that might help get back to the Redmine level. But... 4. ...Redmine evolves clearly faster than TRAC. Lot of releases per year, almost all easy to update. Even if Redmine lacks some features I'd like to see in both TRAC and Redmine, it have better chance to implement them first. 5. Ive posted tickets on redmine project telling what I think is wrong in it. I did the same in TRAC too. I can provide links if you want, but I'm not sure my experience is really worth so let me know. 6. I've worked with Jira before. It's good too but I think the request interface is as bad as the TRAC one (that might be personal). Although, there don't seem to be any way to setup a specific ticket workflow (that is vital to adapt the tool to your specific team organisation) but I'm not sure about that (didn't have access to the server where our JIRA was hosted to see how it's configured). 7. A lot of people (including the OGRE library implementation leader) tried to move from TRAC to Redmine with success. I though to do the same for my bigger project but some things in Redmine makes me think that I should stay with TRAC for the moment. So my current thinking is that TRAC is good enough if you have already a project in it, would be even better if the next release comes not to late( because it is almost always too late) and it's a good idea to watch Redmine evolve because it might get really quick to the point it's the defacto TRAC killer. That said, if boost does split libraries (whatever how), that would imply having multiple projects in TRAC. My 2 cents on this specific point. On Tue, Dec 28, 2010 at 15:08, Vladimir Prus <vladimir@codesourcery.com>wrote:
Klaim wrote:
No, I mean that I'll be opposed to visiting 4 different issue trackers for 4 different components I maintain. I want to see a single list of issues on my plate, so that I can prioritise them together.
Isn't it more a issue tracking problem? TRAC is well known to be able to manage only 1 project (that will change with coming versions) I've used RedMine to compare with TRAC, it allows managing hierarchies of projects and having cross-project ticket requests too. I'm not advocating for a change to RedMine but just that TRAC could be updated (later not now) to manage libraries as different projects (that can share the same repo or not). I'm saying this because I know that the component field alone isn't powerful enough when it comes to managing different modules or libraries inside the same organisation. It's better used to say if the ticket is about documentation or not for example. That said, I'm talkign about features not available yet in TRAC and I don't know exactly the cost of moving a big tracker database to another one, so ignore my humble comment as you wish :)
I have heard positive comments about Redmine, too, exactly concerning its ability to work with multiple projects better than Trac. However, I don't have practical experience with it, so whether it is better than Trac enough to migrate is something we should determine when/if Dean or something else posts a specific proposal to move from Trac.
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost