On Fri, Jun 20, 2008 at 12:22:30AM +0200, Endre Bakka wrote: > > >> 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 > > > > It would be good to get feedback about why ppl feel this way. Noah has > > talked about trac-hacks++ and a nice plugin installer. That would go a > > long way to dispel the notion that "trac-hacks" are bad. I also think > > Two reasons: > - Trust > - Maintenance > > Trust: If you install Trac in a company environment, downloading plugins > from "track-hacks.org" does not give you a good feeling. Moving the most > commonly used and actively maintained plugins to the main site would help > a lot. Adding a note that says "These plugins are mostly maintained by > Trac developers, but kept outside Trac because they are not considered to > be core functionality" would also help.
I agree there is much that could be done as far as branding of trac and trac-hacks. As a developer and my organization's "trac guy", this doesn't really concern me as I have taken the time to investigate plugins and see what works for our needs. Why trust any software found on the internet? Generally, people do so because the site isn't irreputable and the software (at least from the description) seems to fit their needs. An open-source bug tracker is not going to have the same perceived guarantee of commercial software, and will take more expertise to install and configure. I agree much could be done to make the perception better and improve documentation especially regarding general use case and "how to make trac do what you want" (user stories). Putting all plugin functionality in core and bundling it together would not improve my trust of the code; it would decrease it, as it would make trac more of a monolith, regardless of whether all the switches to turn things on or off would be shown (and if they were all shown, I would guess the plethora of configuration options would overwhelm new users). I can see how doing this would increase the perception of the "unified nature" of the code to some people, particularly those that just wanted to throw up a bug tracking system without really figuring out how it works. But I think much more could be gained by making installation more straight-forward (front-ending it, that is) and adding documentation and bettering the sites' branding. > Maintenance: The number of orphaned plugins on track-hacks explains why we > worry about this. Will my plugin be maintained and work with the next > version, or will it just get me into a shitload of trouble? This is a general issue of all software, and I don't think applies particularly to trac or component architectures. I think the process in trac is more straight-forward than for many OSS projects. If a plugin is not maintained, I'm sure most authors would be glad to let outsiders take over their projects. Even ignoring this, the wiki is edittable and patches can be posted, and at worse, plugins can be forked. I think the trouble is finding developers who will step up to the plate to do the maintainence work. Shifting more plugins to be part of trac core doesn't ease maintainence, it just shifts the workload to the core developers. Some plugins (or parts of some plugins) are slated for core, but I think by allowing and encouraging third party plugins trac not only gets more community participation but also free development on matters that users really care about. None of this is an answer to the IT manager that wants a bug tracker to work out of the box yesterday. I'm not ignoring that concern, which I think is valid, but it isn't one of my concerns. I don't know if trac is currently at a state where it fits that use-case. As someone who is content to tweak and do detailed setup, I'd rather see more core development effort go to the guts of the code than to making things easily integratable for those that want an out of the box solution. Jeff Hammel The Open Planning Project http://topp.openplans.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
