There are plugins for much of this.  I'm only to speak to a few specific issues 
as most of these have been addressed by others in this thread:

On Wed, Oct 01, 2008 at 08:51:25AM +0300, Jani Tiainen wrote:
<snip/>
> Trouble #3: Multiproject/multirepository support. We have few projects 
> that are actually combination of several (separate) repositories but 
> also there is few libraries that should be linked (and again, cross 
> referenced, see trouble #2) together tightly. (Not loose coupling like 
> external links)

There is a multirepository branch that is supposedly in good shape (I don't 
have need [yet] for a multirepository trac so I haven't used it).  I'd love to 
know when/if this is slated for trunk.

> Trouble #4: Web based environment creation.

There are actually a few of these.  TracForge does this.  I've also written a 
trac project templating system, th:TracLegosScript, one component of which is a 
TTW project creator.  Its not really ready for prime-time as there are missing 
features (importantly, DB type and authorization checking) but most of what I 
care about is there and I'd be happy to elevate ticket priorities if anyone 
wishes any of the "missing features".  There are a few more that I can't 
remember now.

> Trouble #5: Userinformation retrieval from our LDAP server. Specially 
> active accounts (since sometimes people come and people leave) and 
> e-mail addresses.

Personally, I'd like to see an IUserDataProvider interface to make this more 
flexible.  So the LDAP plugin could provide this, OOTB trac could implement 
what it currently does as an implementation of this interface, and a 
multi-project solution could implement whatever it wants (possibly delegating 
to a master environment).

I'm also pro keeping the notion of multiple projects out of trac core.  What I 
would like to see is more infrastructure so that it is easier to write plugins 
that interface between trac projects.  I'm happy to ticket this if its 
generally wanted and not too contraversial.  

As a note, I think trac's role is as a good infrastructure to build the ideal 
bug tracking system.  I think trying to get trac core to be OOTB an amazing bug 
tracker is a bad idea, as folks have different needs (and even projects for the 
same folks have different needs).  This has all been discussed before and I 
think people are starting to work towards making it easier to get OOTB trac to 
be easily modified to what a trac administrator wants -- a platform that is 
easily customizable via plugins, etc.

Jeff Hammel
The Open Planning Project
http://topp.openplans.org
IRC: jhammel, k0s

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to