On 12/25/2011 4:32 PM, Steffen Hoffmann wrote:
When facing the growing Trac functionality and the current amount of plugins at trac-hacks.org and elsewhere, the call for better overview, easier plugin selection (get best plugin for given task) and convenient feature-enriched packages for better 1st-time user experience is only consequent.
It's perhaps also the right time to make a short list of plugins that could be bundled to the core in some form or another. Bloodhound will probably deliver a wider set of plugins than us, but even for the "core" Trac distribution I think it would be good to integrate more default optional components. For example take the XmlRpcPlugin, it's heavily tied to what the Trac API delivers, it is already maintained by a Trac developer and we already discussed that both Trac and that plugin could benefit from some refactoring to share more code [1]. That would be one of the candidates. The GitPlugin would be another, etc.
[...] There is a saying: 'You know me by my actions, not by my words'. Among other things it had been announced by Wandisco representatives, that current (trac-hacks) developers and plugin maintainers would be contacted to speak about possible ways of collaboration. While I felt like this would qualify me at least for AccountManagerPlugin and TagsPlugin, I've heard nothing by now.
Well, the AccountManagerPlugin and TagsPlugin are also popular ones that could get bundled in some form or another.
If you don't see my point here, just one more thought: Today professional, key-turn application roll-outs are often virtual machines in cluster setups. How could we encourage wider Trac adoption more economic and sustainable within tight resource constraints, if not by working closely with OS vendors? I don't see, that anyone here goes into building images for VMware, VirtualBox, Xen& Co.
What about http://bitnami.org/stack/trac ?
[...] I heartily welcome new developers joining here. Familiarize with the Trac ecosystem, become a part of it. You'll be respected and encouraged to take responsibility according to quantity and quality of contributions as I witnessed several times by now. Having sponsors to donate paid developer time could even yield a leap-frog progress at some issues.
Indeed. Until the Bloodhound mailing lists are created at the incubator, and why not, even after that point, it would be good that Bloodhound developers join the open discussion here in trac-dev@googlegroups.com. Also, it would be nice to announce the creation of those mailing lists here, so that interested parties could also join the discussions that will take place there.
OTOH a diversion won't be good for any of the involved parties. Trac (plugin) developer base could be finally drained below the critical mass to do both, maintain existing solutions and produce remarkable, valuable new stuff
That's indeed a risk. As osimons reminded us, there's already quite some maintenance work needed to have a plugin supported across several Trac major versions. Ideally Bloodhound and Trac should retain some level of compatibility. The big question is: do they intend to "fork and forget" i.e. copy the code at some stable point (0.12.3? 0.13?) and then forget about t.e.o's version of Trac and only focus on their own code, or to the opposite, keep the changes from "upstream" flowing in and regularly merge from t.e.o? I think the latter option makes the most sense and will help to preserve a good level of compatibility.
Just for getting the fame of Trac and respect of the community for this project into the Apache domain? I hope this isn't the hidden meaning of the Bloodhound proposal, and most probably it won't work out in the end anyway.
Certainly not. I think Apache doesn't need or care to get the Trac "fame" and on our side we're not so interested in being covered by the Apache "brand" either. There's no hidden meaning to the Bloodhound fork, it's really just WANdisco wanting to do some business with Trac as a starting point. As opposed to other companies who do the same, they want to do it publicly as open source and they settled on Apache to host their effort. This gives us the opportunity to have a look on what they're doing and to take things back if we happen to find their changes interesting. In that respect, it's a bit more interesting than if they kept their changes private. The downside is the risk of fragmentation, but I think it can be handled with appropriate communication between the interested parties.
-- Christian [1] - http://trac.edgewall.org/ticket/10125#comment:15 -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
