Re: [boost] Respecting a projects toolchain decisions

Subject: Re: [boost] Respecting a projects toolchain decisions
From: Klaim (mjklaim_at_[hidden])
Date: 2010-12-28 09:53:11

If you have any interest in testing it without having to find a server host
available and having to install it yourself (it's not as easy as they said,
even TRAC is simpler...), I can create accounts to my "private" installation
(on a publicly available server) that is mostly setup to experiment and
compare with TRAC (so you can play with it without bothering about side
effects on other projects inside it).

Just tell me (and others too) if you want an access to play with it. I'm
wishing to help improve boost any way I can. :)

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
> 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
>