Subject: Re: [boost] Respecting a projects toolchain decisions
From: Klaim (mjklaim_at_[hidden])
Date: 2010-12-28 10:12:44
(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
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
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
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_at_[hidden]>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
> > 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
> > 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk