on Fri Jun 27 2008, Noah Kantrowitz <noah-AT-coderanger.net> wrote:
> 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. One of the simple ease-of-use upgrades I've had in Trac for a long time is the functionality proposed in http://trac.edgewall.org/ticket/5340. This was (at one point anyway) a one-or-two-line change that made the Trac user experience substantially better for most auth methods one might choose. In fact, without it, I have had numerous smart, experienced tech people become confused (and some of them angry!) when they see Trac's permissions errors instead of a login screen. IMO, the empirical user feedback speaks for itself. I can't blame them, either. Show me one other popular web software package that generates such a loud permissions error while hiding the "fix" away in a little link that is not very prominent when the error occurs. The suggestion in the ticket was to use http://trac-hacks.org/wiki/PermRedirectPlugin. Problems with that: 0. The total amount of code required to package this as a plugin compared to what it would take to integrate it into Trac doesn't make economic sense from a maintenance point-of-view. But in theory that's not my problem. 1. Other Trac administrators have to discover this plugin in order to get up to what many people consider a minimally acceptable level of usability. 2. The plugin isn't working with 0.11; at least not for us. This plugin, as it is developed by Noah, by rights ought to stand a better chance than many others of maintaining compatibility with the Trac release. I don't think this would have happened if the functionality was in the Trac core. In fact, I'm pretty sure that #2 above is at least partly related to #0. I'm not trying to say that lots of plugins ought to be pulled into the core. I share the OP's point of view that the separation and modularity is beneficial. The current approach appears to be "if it can go in the core, it should"... sometimes. For example, it's my impression that there's a lot of wiki formatting functionality in the core that could be in a plugin. I think, at the very least, the criteria for deciding what belongs in the core ought to be revisited, nailed down, made consistent, and then publicized. If the policy were clear, consistent, and known, I bet you'd stop seeing clones of this thread pop up every few weeks. -- Dave Abrahams BoostPro Computing http://www.boostpro.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 -~----------~----~----~----~------~----~------~--~---
