On Jun 27, 2008, at 1:13 PM, Scott Bussinger wrote: > “Trac Options” would also be included in the base Trac installation > but disabled by default. Again, a nice admin page for enabling these > optional features would be great. These option plugins would be those > particularly useful/powerful plugins that the development team deems > stable enough and appropriate. The key here is that these option > plugins would be maintained as part of the Trac release process. The > whole point here is to keep the core lean and not weigh the core down > with unnecessary plugins being loaded, but ensure that if you enable > one of these optional features it will continue to work if you upgrade > Trac to a new release. Examples of these would be the existing sample > plugins like Timestamp as well as extremely popular plugins like > AccountManagerPlugin. > > “Trac Plugins” would be all the other stuff from trac-hacks.org and > would be handled pretty much as it is now -- a free-for-all that can > include anything, but it’s up to the user to ensure that a plugin is > compatible with a new Trac release. > > This would make it easier for people to gain access to features that > are very commonly used but don’t need to be part of the Trac core. It > would also simplify the upgrading process to new Trac releases (since > you’d know that optional pieces you depend on are already compatible). > The space requirements are trivial (it’s not like plugins are very > big). Since the Core Features and Trac Options are constrained lists > known in advance, we could have special admin pages that simplify > enabling/disabling these plugins to customize a Trac installation. > This could really help out new users. Voting on the mailing lists > could handle moving a plugin into the Trac Option category. > > I'd like to see a fairly large number of the commonly used plugins > moved into the Trac Option category. In some cases there should > probably be a bit of refactoring of the existing plugins to follow a > more cohesive plan, but that can be worked out as we go. > > I hope I didn’t step on any toes here, but I do think this would help > people take advantage of Trac.
This shares the same issues as the current system. People will still want their favorite feature made into an "option" instead of a plugin, and bundling things removes most of the benefits of using plugins. There is a very simple way to fix this, we need to remove the distinction between "Trac" and "plugins". Trac is just a collection of plugins you install, and it needs to be easy to install more. Quality control is an issue, but it will always be an issue. Community ratings will help that though. Having more divisions will cause problems not fix them. --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 -~----------~----~----~----~------~----~------~--~---
