> -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Alec Thomas > Sent: Friday, June 20, 2008 7:18 AM > To: [email protected] > Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong > with Trac? > > > 2008/6/20 [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > > > I vote for Trac being shipped with a package of commonly used plugins > > (AccountManager, AutoQueryPlugin, IniAdmin etc.). > > AutoQueryPlugin is a perfect example of the effort surrounding > including plugins in Trac. I'm not bashing the author, but the major > blocker is mentioned on the plugins page: "This plugin overrides the > ticket.html template to do this. Ideally, this wouldn't have to be > done, but it was the easiest solution to the problem." > > This plugin couldn't be shipped with Trac with that approach. > > TBH, this would be better implemented as a patch against trunk. If one > were provided it would likely be included. > > > > > By the way, what is the evaluation process used (or that should be > > used) to decide if a feature/plugin/whatever should be included into > > Trac or shipped with Trac? > > Historically, the WebAdmin and Spam plugins are the only two imported > into Trac. Both started life as plugins hosted on t.e.o, both were > written by cmlenz, and both were imported by him. Both were also long > overdue. > > However, so are others in my opinion: AccountManager definitely. > > Trac developers, I think we should take a vote on the following: > > I propose we move high (or even medium) quality, popular plugins > onto t.e.o. Perhaps into the sandbox or a new "plugins" path > initially. Then ship them with Trac, configured but disabled. If the > plugins stagnate, we remove them, or we pick up maintenance. We change > our model to rely on plugin authors to maintain quality plugins within > Trac, rather than treating them as second-class citizens of the > community.
-1. You are trying to solve a PR problem with a technical solution. There will always be that one plugin that someone wants, that we don't include. Unless you propose to basically merge t.e.o and trac-hacks (possibly not a bad idea eventually, but not a discussion for today), this won't do much IMO. You know and I know what plugins on trac-hacks are up to snuff, and we are quite clear about it in many places (see how many guides recommend installing AccountManager). I would propose an alternate solution, the creation of a "new" project that is officially recognized by t.e.o in some way as being the turnkey solution so many people want. Perhaps something like bitnami+oforge+some common options and config settings. "Trac" remains the minimalist system we all know and love, and anyone installing it will continue to get the same experience. People wanting the turnkey version can get $NEWPROJECT, and not care about what particular components it pulls in. --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
