> -----Original Message----- > From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] > On Behalf Of Gary Oberbrunner > Sent: Wednesday, October 01, 2008 12:50 PM > To: trac-users@googlegroups.com > Subject: [Trac] Re: Trac in trouble. > > > Noah Kantrowitz wrote: > > I have also explained many times on this list why we have put off > multiple > > project support (including subprojects), but just for kicks: > > > > People are very quick to ask for "multiple project support", citing > tools > > like GForge or Redmine that can do it so it must be easy. This fails > to take > > a very important part of the Trac philosophy into mind; we go as far > as > > humanly possible to not enforce any project management philosophies > on the > > end user. The fundamental problem with mutli-project support is that > if you > > ask 10 people what they want from it, you get back 10 different > "critical" > > feature lists. This leaves us in a quandary. Constructing a single > design > > that allows all of those styles is incredibly tricky and not > something that > > can be done overnight. If someone has suggested such an overarching > design, > > I have yet to see it. The simple solution to this for right now is to > leave > > multiple project handling in the domain of plugins and scripts for > right > > now. This means each plugin can experiment design-wise without > impacting the > > users of another plugin. Over time I suspect we will see a small > number of > > these plugins become the de-facto standard, and then at that point it > is > > much easier to talk about integrating the few "winning" designs into > Trac > > core. So, in short, if you think mutli-project support is easy and > know how > > it should be done, go prove me wrong. Really, I won't be offended. > Make > > something that everyone acknowledges is The Right Way To Do It and we > can > > move forward, but without that we have bigger fish to fry. > > Interesting. I didn't realize it was so controversial! It seems to me > that implementing http://trac.edgewall.org/ticket/1048, which is > basically my suggestion from > http://lists.edgewall.com/archive/trac/2005-May/002932.html, and the > leading suggestion from #130 as well, would be easy and would satisfy > at > least some of these requirements, without precluding other different > multi-project models -- so IMHO it escapes your quandary about needing > one overall architecture that satisfies all comers. Also doing this in > a plug-in is quite difficult. I guess I just don't see the downside to > adding a Project table and related fields. (And btw this is exactly > how > Redmine does it; see > http://forge.typo3.org/repositories/entry/team- > forge/redmine/db/schema.rb).
And, as many people have noted in this thread, redmine is generally quite inflexible. There is always a downside to everything, adding more code is a higher maintenance burden if nothing else. I do agree that I think that model is a step in the right direction for single-environment mutli-project, but it isn't the full picture (yet). --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
