+1 to this latest thread. This is my third company using Trac and I've contributed a number of plugins over the years: http://trac-hacks.org/wiki/robguttman
Ethan's point about configurability is exactly why I prefer Trac over others. I don't know enough about Bloodhound to comment on specifics. In general, I like the idea of people wanting to contribute more to the Trac community. But if the effort is likely to spread limited resources even thinner, that concerns me. I would rather see more support for Trac as we know it such as bringing trac-hacks.org up-to-date (possibly at a new home if necessary) and making it as supportive for collaboration as github (e.g., through new plugins). That's what I think the community really needs from this humble plugin developer's perspective. - Rob PS: Happy holidays! On Dec 25, 2011, at 10:55 AM, Ethan Jucovy wrote: > 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. -- 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.
