Thank you, Simon and Steffan -- +1 to everything you have both said. I am a deeply committed Trac user (since 2006), occasional plugin author and casual observer of the core codebase and development process and I share your concerns about the Bloodhound effort. In my experience Trac's design and architecture make plugin development very easy, and I am not sure what value there is in a pre-emptive fork that does not first attempt to work within the existing core architecture and community processes.
Of course I understand that a corporate effort will generally need to commit upfront to getting its own goals accomplished as a higher priority than working with upstream constraints. But to reframe that reasonable internal prioritization as an open source fork under the Apache name seems detrimental to everybody, as Simon and Steffan have said. Again repeating what others have said .. the Trac community could certainly use more and better integrator-level documentation, configurations and "known good sets" of curated plugins, explicitly managed outside the Trac core development process. But there is no reason per se why this should not happen at a symbiotic layer sitting on top of the Trac core -- not a pre-emptive fork. To answer Simon's question, I plan to monitor Bloodhound development, but I do not expect to switch to using it or developing against it. The Trac code and community have consistently impressed me as a good, reliable, streamlined base that I can configure to do pretty much whatever I need. The very action of announcing an intent to fork, rather than working in and atop Trac's well-designed and long-established component architecture system and plugin community, makes me think that the Bloodhound project is likely to bake in a more opinionated, less robust and less configurable core. On Sun, Dec 25, 2011 at 10:32 AM, Steffen Hoffmann <hoff...@web.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 25.12.2011 04:14, schrieb osimons: > > Hi Trac & (future) Bloodhound communities. > > > > I have previously shared my thoughts in bits & pieces in various > > communication with interested parties, but for the sake of openness > > and clarity for all I figured a public summary would be in order. > > > > ... > > > > People? Thoughts? > > Thanks for asking. > > My roughly 3 years of slow progress towards becoming a member of the > Trac community won't let me speak as authoritative as you, Simon. And I > didn't follow Apache general incubator mailing list at all. Anyway, I've > read all announcements about the upcoming Bloodhound fork here very > carefully and I confess that I'm sharing a lot of the uneasy feelings > with you. > > I learned that Trac has a really small developer base these days. So > small, that it hurts me at several occasions, because noble ideas simple > can't be approached for the lack of time and maybe other resources too. > OTOH, two new developers have been invited and joined the core team this > year. And while obviously not involved with many fancy new features, as > often as I looked into recent commit history I've seen all of them doing > rather ambitious work behind the scenes. Better API documentation, > continued db backend re-factoring, progress towards more i18n support > for wiki content and many small fixes and enhancements come to my mind > instantly. > > Certainty, there are a bunch of alternative wikis, repository browsers > and bug trackers out there. In my eyes Trac is still unique for it's > consequent "reduce-to-the-max" core design and rather rigid policy of > using plugins for may tasks, that are considered part of core elsewhere, > and renown for it's plugin support too. > > 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. As a Debian user I'd solve this by better support for > distributors. Btw, I already established contact to the Debian Python > apps packaging team myself, this has been very welcome, but I had no > time to contribute there by now. > > I fear that my English isn't good enough to point out critical issues > with the Bloodhound proposal. I'm with Osimons for the most of his > gentle rambling against the massive effort for just the fork, and that > the true shape of the new project seem still very blurred and unclear. > > 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. > > Not that I'd need that special attention. I don't complain at all. In > fact I would be a bit lost for words in the current situation. What > should I expect? What will be expected from the other side? I could > never compete to professionals doing it full-time as their daily > business. As a non-professional in the software development business I > can only dedicate a small part of my private life to work on Trac and > plugins, mostly late evenings, after children went to bed. > > Inside the Trac community this has never been a problem so far. Even > with initially very few coding experience I've found patient listeners > and professional advice on my requests here at the mailing list as well > as at #trac IRC channel. When I had a serious Trac problem and was in > doubt, if I could approach that or better give up, Simons hints and > encouraging words confirmed me to stay and try. Just one occasion that > I'll never forget. > > I'm thankful indeed and eager to give something back. My current plugin > maintainer status and loose affiliation with Trac core will continue, at > least until it is clear that Bloodhound will become the new Trac. But > this won't happen easily. Most announcements suggest effort that could > and maybe better should be done inside Trac and trac-hacks for more > livid development, and better packaging support by/with existing > operation system distributors on the other side. > > 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. > > 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. > > 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. 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. > > Would love to hear more people to speak-up here too. > > Steffen Hoffmann > (hasienda) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk73Qf8ACgkQ31DJeiZFuHeIrwCgpGNNzIz32ctnG3hze5kHvjlL > j2cAoOTeV1A2w+0P72M0D7vGg+qUqRcg > =HhL5 > -----END PGP SIGNATURE----- > > -- > 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. > > -- 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.
