Seasons greetings to all,
I'm very pleased to see a discussion starting on this. I was hoping for an
ongoing open dialogue and co-operation between the Trac and Apache
Bloodhound efforts and would encourage as many people as possible to get
involved in this dialogue. I'm concerned that anyone here regards Apache
Bloodhound as a threat to Trac. Whether this ultimately develops as
a 'friendly fork', derivative or something else, managed properly both
approaches can succeed and give to each other without jeopardising
the viability of either.
There may be questions that it is too early to answer, however I can
address a few of the previous points now. WANdisco spent the last year
investigating how we could most effectively participate and make a large
investment in the development of an open source defect tracker to
equal equivalent commercially available tools. In many software categories
there are open source tools that take on and often hands down beat
commercial options, but that's not true for any open source defect tracker
today. Our view was that Trac represents the best vehicle to achieve that
and working within the existing infrastructure was discussed at some
length.
The Trac ethos is a fine one, which can be equated to an advanced assembly
kit that people must put together in just the way they want before they can
effectively use it. There are companies that offer pre-configured versions
of Trac and professional services around it, but there is nothing that an
average tools manager or evaluator can quickly test, use and deploy as part
of an accessible open source package. That's not all there is to the Apache
Bloodhound proposal, but it's important to highlight that there is a
difference in approach and goal there. I personally don't believe either
approach is wrong, just different.
The benefits that an open source foundation can bring to any project are
well documented. As well as gaining an existing development and tools
eco-system, the strong governance and very important legal protections that
the Apache Software Foundation provide are not matched by the current Trac
setup. As a business investing heavily in an open source project we are
duty bound to ensure certain things about our investment. The impression we
got from the existing 'core' of the Trac group was that they wouldn't be in
a position to put those things in place and it was they who suggested that
the best way forwards was a friendly fork.
So now WANdisco is gathering a strong team who will work on this as part of
a wider Apache based community. It isn't anyone's intention to detract from
ongoing Trac development in anyway and I don't believe Apache Bloodhound
will. As part of Apache there will be a community who would hope to take
the best things from Trac, and I'm sure work to address the other points
like Trac-hacks and the plugin eco-system among others. In no circumstances
will we want to do that in a way which would undermines Trac though and I'd
hope that all of these areas can be discussed and agreed upon as they are
being approached.
It's still early days and there is a lot of work to do. Within Apache the
discussion will be open and available to anyone who wants to get involved.
I don't think anyone should feel under pressure to do that, but you're more
than welcome. I'd also be happy to facilitate ongoing discussions, maybe
even calls and video conferences between us all to ensure that we aren't
conflicting and ultimately that we're providing the best possible software
for users.
Best Wishes,
Ian
--
Ian Wild
Director of Engineering
WANdisco, Inc.
http://www.wandisco.com
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion
Subversion community
http://www.svnforum.org
On Sun, Dec 25, 2011 at 4:30 PM, Rob Guttman <***@gmail.com> wrote:
>
> +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 <***@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-***@googlegroups.com.
>> To unsubscribe from this group, send email to
trac-dev+***@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-***@googlegroups.com.
> To unsubscribe from this group, send email to
trac-dev+***@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-***@googlegroups.com.
> To unsubscribe from this group, send email to
trac-dev+***@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
--
--
Ian Wild
Director of Engineering
WANdisco, Inc.
Cell : +44 (0)7961193722
Office DDI: +44 (0)114 3030472
US: +1 925 3801734
http://www.wandisco.com
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com <http://www.ubersvn.com/>
Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>
Subversion community
http://www.svnforum.org
--
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-***@googlegroups.com.
To unsubscribe from this group, send email to trac-dev+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.