On Jun 20, 1:22 am, "Endre Bakka" <[EMAIL PROTECTED]> wrote: > >> Unrelated to this is the idea that doing things in plugins is bad. I > >> really don't understand where people get this idea.
> Two reasons: > - Trust > - Maintenance I totally agree. Plugins aren't bad as a technical solution, the problems come from "trust" (in the general sense, e.g the quality of the code etc.), maintenance and other user experience problems (I wrote recently about first not finding and then trying to figure out which one of the 3 Wiki Include plugins to use). I'm also wondering what is the additional cost for users to include "extra functionality that not everyone uses"? I think the intersection of functionality that everyone uses is about an empty set anyway... Having much more functionality available right out of the box (but still configurable of course) would be much more user friendly. I wouldn't worry about increasing the package size or even the Trac process size. Including optional functionality in the "core" (as plugins or as core features not using plugin APIs) would also have the same kind of benefit that Linux has with their divers: when you make changes to unstable APIs the core maintainers can pretty easily make fairly mechanical search+replace through the code tree to update the plugins. It would require much more for each individual plugin maintainer to do the same. I think Trac could also encourage experimentation by assigning some APIs non-frozen or experimental and the others as frozen (Mozilla does this, yes). Trac-hacks could be the place to experiment with plugins using experimental APIs to see if they work in practice and can be frozen in some future release. I see Noah and Endre talk past each other, because Noah looks only at the developer experience (Trac code is perfect and we keep releasing only perfect code, plugins don't have technical problems) and Endre thinks about the user experience (Trac is highly imperfect for almost every use case since it contains only the common subset of features everyone needs and that is close to the empty set, figuring out what plugins to use is a pain). There are no technical solutions to address Endre's comments, it's about the mindset and attitude. If Trac is not just a programming exercise, it needs to pay attention to the user experience as well. I know Linux and Firefox (and git) are not perfect, but I thank their developers for not trying to make them perfect and force me to use some other non-perfect OS and browser. It's also a fallacy that people would switch using the perfect Trac (or OS or browser) once it is released in the distant future; good enough is good enough for users. The perfectness of the code is not a value in itself, it's only a means to make a better product faster. Having a rapidly improving product also attracts more developers which helps to improve the product faster and making less short-cuts while doing so. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
