On Jun 27, 7:19 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > 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
First, I have to agree with the sentiment that Trac needs plugins and that plugins is pretty much a requirement for any non-trivial test setup. However, as Noah says, exactly what plugins one needs will depend, and it is exceedingly difficult to make something that suits all - especially handled and coordinated by the Trac developers that also have a ton of other current and future fixes and enhancements to focus on. What I would like to see would be that people with similar needs came together to maintain 'community' versions of their Trac setup with a set of plugins they would need for their use. Using svn:externals it could pull in Trac source and plugins and other third party modules as it needs (pegged at certain tested revisions for instance), and the only additional code would be a tried & tested script to install and upgrade everything correctly + perhaps some minimal scaffolding to make it all come together; virtualenv setup, fixed folder structure, fcgi/wsgi scripts working out of the box and similar. A community version for consultant shops, a version for internal software development, a version for community projects and so on. Bundle in a custom theme, recommended workflows, reports, permission setup and the like. It would work best by being based on what some organisations ause daily, and are prepared to invite others in to help use, test and maintain. That would a) make it easier to install, deploy and maintain, and b) make sure that different Trac and plugin combinations got tested and maintained, and c) offered a secondary support path for users for issues that are strictly not related to Trac development itself. I am not a great believer in the design-by-committee, and the everything-delivered-and-supported-by-Trac based on popular vote is guaranteed to be a frustrating experience for everyone involved. :::simon https://www.coderesort.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
