> 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.
How big a problem is this really? It seems like it wouldn't be hard to draw a line between plugins that offer generally useful functionality (Trac Option) versus those that are a rather specific (Trac Plugin). For instance, a WYSIWYG plugin is generally useful. The GraphViz plugin is pretty specific. The BackLinks macro is generally useful, an IRC plugin is pretty specific. To pick a more potentially controversial example, a plugin that adds some simple time accounting fields might be generally useful, a plugin that turns that information into a scrum burndown chart would be pretty specific. > Trac is just a collection of plugins you install, and > it needs to be easy to install more. I wholeheartedly agree and that's why I made the suggestion. Improving the process of loading third party plugins would be great. My suggestion revolves around making it as easy as you possibly can to load some of the most common and most useful plugins (i.e. by pre- installing them even though you wouldn't pre-enable them). > Quality control is an issue, but it will always be an issue. Quality control is a problem, but also some assurance that common (and critical) plugins will work when Trac is upgraded is important as well. Perhaps the number of API changes in recent releases of Trac is atypical, but the number of plugins designed for Trac 0.9 that still work without change in 0.11 seem rather limited. Look at the comments in the newsgroups from people who are still running old versions of Trac (like 0.9-era). For them to update to the new 0.11 release is likely to be a non-trivial exercise. > Having more divisions will cause problems not fix them. I'm not sure I agree with you on this one. Organizing can be helpful. Look at trac-hacks.org for instance. There are sections for "Integrating Trac with 3rd party Applications", "Macros", "Patches", "Plugins", "Scripts", "Themes", "Translations", "Tutorials", and "Ticket Workflows". Some of those distinctions are real in the sense that are used in very different ways (e.g. the scripts are generally utilities used outside of Trac itself, whereas patches are special modifications to the Trac source code). Others are artificial distinctions, such as macros and plugins. Macros are just plugins with a particular purpose in mind (tweaking the Wiki engine). The same for Themes. Those divisions are useful distinctions that make it easier to find what you need. And that makes it more likely that a new user will take advantage of them. The intent behind my proposal is the same -- to make it easier for new users to take advantage of Trac. Note that I don't want to get in the way of the experienced users, but I don't think this proposal would. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
