2008/6/20 [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > I vote for Trac being shipped with a package of commonly used plugins > (AccountManager, AutoQueryPlugin, IniAdmin etc.).
AutoQueryPlugin is a perfect example of the effort surrounding including plugins in Trac. I'm not bashing the author, but the major blocker is mentioned on the plugins page: "This plugin overrides the ticket.html template to do this. Ideally, this wouldn't have to be done, but it was the easiest solution to the problem." This plugin couldn't be shipped with Trac with that approach. TBH, this would be better implemented as a patch against trunk. If one were provided it would likely be included. > > By the way, what is the evaluation process used (or that should be > used) to decide if a feature/plugin/whatever should be included into > Trac or shipped with Trac? Historically, the WebAdmin and Spam plugins are the only two imported into Trac. Both started life as plugins hosted on t.e.o, both were written by cmlenz, and both were imported by him. Both were also long overdue. However, so are others in my opinion: AccountManager definitely. Trac developers, I think we should take a vote on the following: I propose we move high (or even medium) quality, popular plugins onto t.e.o. Perhaps into the sandbox or a new "plugins" path initially. Then ship them with Trac, configured but disabled. If the plugins stagnate, we remove them, or we pick up maintenance. We change our model to rely on plugin authors to maintain quality plugins within Trac, rather than treating them as second-class citizens of the community. We have ideas for making plugin integration even smoother, such as automatic installs from t-h, a plugin "configuration" web interface, but these are quite a way away and people need these features. Why are we persisting in making life difficult for our users? (For general information, each plugin on http://staging.trac-hacks.org/hacks is weighted by the number of hits from the trac-hacks apache logs. It's a fair metric of popularity, but not necessarily quality. XmlRpcPlugin (which I wrote), for example, is really horrible code. I'd be disturbed if it were included with Trac.) Anyway, it's late and this is probably incoherent, so I'm going to bed :) > > André > > On Jun 20, 10:17 am, Risto Kankkunen <[EMAIL PROTECTED]> > wrote: >> 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. > > > -- Evolution: Taking care of those too stupid to take care of themselves. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
