> -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Jani Tiainen > Sent: Thursday, June 19, 2008 1:11 AM > To: [email protected] > Subject: [Trac-dev] Re: Is Redmine a better Trac? What's gone wrong > with Trac?
[snip] > But still it feels that there is not much of real discussion how to > implement and possible solutions. Most of requests are bypassed by "use > a plugin" or "do a plugin" statements. It's a bit annoying specially > since it makes you feel that you need to trust some hacked "3rd party" > tool. This is true. We do avoid discussion of some things when we know there won't ever be a clear way forward without action. In the example of multi-project support, I have been quite vocal that people should build examples of lots of different models, and see which ones people like. This is why I have spent so much time trying to build TracForge. Unrelated to this is the idea that doing things in plugins is bad. I really don't understand where people get this idea. Trac is already just a plugin framework, and some bundled plugins (wiki, tickets, timeline, etc). There is no fundamental difference between 3rd party stuff from trac-hacks, and Trac itself (other than decoupled release dates, smaller codebase, etc). I wrote a long rant on this on my blog (http://coderanger.livejournal.com/23087.html) so I don't feel I need to repeat it all here, but the short of it is that people need to stop thinking "plugin" == "bad". [snip] > Is is really necessary to wait for such a long time (At current pace it > would mean about 89 upcoming releases, each one in about 14 months.. > :D) > to get things done? 1.0 is not just the version past 0.99, it is a statement that we feel Trac is really "stable". Not so much from a normal doesn't-crash-and-eat-data perspective, but in terms of API and feature stability. This is similar to how the Subversion project treated 1.0. That was the point they felt their growing pains were over and they were ready to make promises about APIs and system integrity. I don't really know when this will arrive for Trac, but I am at least content that we have been moving in that direction fairly steadily. > IIRC there has been few suggestions to have some of the most popular > plugins to be part of "core", or at least distributed with core. Yes, when it becomes clear the plugin isn't just additional niceness, but is making up for core deficiencies or is just so widely used that we can't ignore it. This is why WebAdmin has been integrated into core, and some others will likely follow it soon. TicketDelete is an obvious candidate, as is WikiRename, IniAdmin, and parts of AccountManager. There are also plugins that will probably not be simply included in Trac, but I am certainly keeping an eye for possible API or UI stealing (BatchModifyPlugin and AnnoucerPlugin come to mind). Mostly it is a matter of someone putting in the time to integrate the feature cleanly and make sure the UI for it fits nicely. --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
