Noah Kantrowitz wrote: >> -----Original Message----- >> From: [email protected] [mailto:[EMAIL PROTECTED] On >> Behalf Of Robert C Corsaro >> Sent: Friday, June 20, 2008 12:29 PM >> To: [email protected] >> Subject: [Trac-dev] Re: Packaged Trac <snip> >> As far as one blessed trac distribution, I don't like the idea. As has >> been mentioned many times, users have different needs. OForge, as it >> currently stands, serves our needs. That of a consulting company with >> many clients. We would expect that our users/contributers would have >> similar needs. It could be that OForge fulfills the needs of other >> types of users, that we haven't even considered. That would be great, >> but we don't expect OForge to be the end all, be all of Trac >> distributions. I think that there is room in our community for >> multiple >> trac distributions that suit different needs. > > Really I don't think there is. Not in a bad way, but it seems like the > insane flexibility we have created can sometimes be overwhelming to people. > The idea of having the One True Turnkey Trac would be that it offers far > fewer choices, but gives a new team the kind of structure and guidance many > people seem to want. This also extends to things like the Trac install > process. Many people don't know which of the dozen deployment options to > choose so they decide "Trac is hard to install", when really getting Trac on > tracd running takes no more than ~10 commands. I think giving people some > kind of package that has all the best practices they have been hearing about > setup and ready to go will lower the barrier to entry for a lot of people. > And if they decide they want the flexibility back, Trac Classic will be > waiting on the sidelines for them.
I agree with Robert here. Having one blessed "turn-key solution" for trac only creates its own problems. Problems I see are: 1) We get tons more bugs on t.e.o regarding external plugins / turn-key integration that should be someplace else. 2) Due to all the bugs and the fact that projectX is the blessed version of trac, trac-core ends up taking over maintainership. This is not a position that we want to be in 3) projectX ends up lagging behind core and or introducing some bugs, the ire of which gets redirected back to core not projectX I think that we should make it clear on t.e.o that there are projects that bundle trac with some of the most popular plugins out there. I think we should list said projects with the plugins/features they provide. I think we should keep that list to absolutely no more than five, and probably closer to three. This way we have "turn-key" solutions that are available, and sanctioned by trac-core, but clearly delineated from trac-core. If we retain control of the wiki page listing said projects, we can keep the list small, and we can verify that the projects are actually decent. We can also make sure that they have a ticketing system and can then refer all tickets that end up on t.e.o to the proper project. I think that if we make only one "blessed" project, then we may as well just make it trac. -John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
