New Trac based project

183 views
Skip to first unread message

Ian Wild

unread,
Dec 2, 2011, 7:32:20 AM12/2/11
to trac...@googlegroups.com
Hi All, 

As some of you may already be aware, earlier this year WANdisco[1] approached members of the Trac development community with a view to working out how we could most effectively invest development time into the project. We plan to use Trac as a basis for a defect tracker supplied with our uberSVN product[2]. Our goal being to develop a tool which can compete out-of-the-box with other non-opensource defect trackers that have gained popularity in recent years.

The resulting discussions were interesting and culminated in the idea that we might get the most done in the shortest time by performing a 'friendly fork' of Trac and running that as a separate FOSS project. It was felt this would present the least risk for everyone involved while still leaving options open for future collaboration. Furthermore, having seen the success that joining the Apache Software Foundation brought to Subversion, we felt that this model could reap many benefits for the community of Trac developers and users and wanted to explore that further.  

Since then we've been looking to bring together a team who could drive these efforts and I'm pleased to say that in the last couple of weeks that has finally been realised. Not only do we now have a full time lead developer working out of our Sheffield (UK) office, with support from a number of colleagues who will contribute significant amounts of time and energy to this work, we are also recruiting additional freelance developers to work on this project as independent committers*.

We have a strong and passionate team who will do all they can to make this a success. However we can't form an entire opensource project on our own. Our first goal is to enable a community to come together which has the strength and depth to take this forwards. While the Apache move is an important part of that, no less important is support from the general Trac community and especially the current and past committers who have done so much to get the software to where it is today. 

I want to be clear that our intention is in no way to undermine the current Trac project and the progress that is making. We hope there can be mutual collaboration and a shared journey. This approach gives us both the freedom to continue with our own strategies while allowing us all to stay engaged with each other and to achieve what I'm sure all of us desire - To make Trac the best defect tracker on the planet. 

At this stage I just wanted to let everyone know we're planning to publish our proposal to the Apache Incubator later today and invite any questions or other feedback. 


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

Ian Wild

unread,
Dec 2, 2011, 7:41:32 AM12/2/11
to trac-dev
Apologies for messing up the subject on my previous post. I forgot Google Groups doesn't add the [list name] automatically. Shall we try again!

...

Ian Wild

unread,
Dec 2, 2011, 11:04:36 AM12/2/11
to trac-dev
On Fri, Dec 2, 2011 at 12:41 PM, Ian Wild <ian....@wandisco.com> wrote:
As some of you may already be aware, earlier this year WANdisco[1] approached members of the Trac development community with a view to working out how we could most effectively invest development time into the project. We plan to use Trac as a basis for a defect tracker supplied with our uberSVN product[2]. Our goal being to develop a tool which can compete out-of-the-box with other non-opensource defect trackers that have gained popularity in recent years.

...

By way of follow-up, the proposal has now been submitted to the ASF Incubator. 

The Apache Incubator mailing list is public so feel free to follow there if you're interested in how this goes. The proposal itself is available in the Apache Wiki at http://wiki.apache.org/incubator/BloodhoundProposal 

Simon Cross

unread,
Dec 2, 2011, 6:36:29 PM12/2/11
to trac...@googlegroups.com
On Fri, Dec 2, 2011 at 6:04 PM, Ian Wild <ian....@wandisco.com> wrote:
> By way of follow-up, the proposal has now been submitted to the ASF
> Incubator.

I read through the incubator proposal and realized that this proposal
is actually much wider than Trac itself and really extends to include
other parts of the Trac ecosystem. As the de-facto Genshi maintainer
(recently self appointed :) and a Bitten developer, I have a couple of
questions:

* Is Bitten one of the plugins you're planning to include in Bloodhound?
* Do you envisage Bloodhound also forking Genshi?

As Genshi maintainer I'm more than happy to accept contributions from
other developers and I'm in the process of cutting a new Genshi
release (although I encountered a few procedural hiccups like needing
access to some Edgewall servers to upload releases).

Personally I'm happy to see people taking a serious interest in
maintaining and developing Trac and friends -- they're all still quite
cool projects and they good do with a little TLC.

Schiavo
Simon

Ian Wild

unread,
Dec 5, 2011, 9:56:09 AM12/5/11
to trac...@googlegroups.com
Hi Simon, 

On Fri, Dec 2, 2011 at 11:36 PM, Simon Cross <hodg...@gmail.com> wrote:
* Is Bitten one of the plugins you're planning to include in Bloodhound?
* Do you envisage Bloodhound also forking Genshi? 

At this point we're still in a period of community building and performing enough discovery to form a detailed plan. As such precise decisions about what will be in the first Bloodhound release are yet to be made. There are a number of plugin authors we'd really like to talk to about inclusion and we will be making that contact in the next few weeks. We'd rather only fork what we have to and one of the goals will be to maintain as much compatibility as we can, so I can't answer the Genshi question just yet.


Personally I'm happy to see people taking a serious interest in
maintaining and developing Trac and friends -- they're all still quite
cool projects and they good do with a little TLC.

That's great. We've been encouraged by the initial feedback and are certainly serious about making this work. I look forward to updating you all on progress once a little more water has flowed under the bridge. 

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



As Genshi maintainer I'm more than happy to accept contributions from
other developers and I'm in the process of cutting a new Genshi
release (although I encountered a few procedural hiccups like needing
access to some Edgewall servers to upload releases).



Schiavo
Simon

--
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+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.


Simon Cross

unread,
Dec 5, 2011, 10:09:21 AM12/5/11
to trac...@googlegroups.com
On Mon, Dec 5, 2011 at 4:56 PM, Ian Wild <ian....@wandisco.com> wrote:
> That's great. We've been encouraged by the initial feedback and are
> certainly serious about making this work. I look forward to updating you all
> on progress once a little more water has flowed under the bridge.

Cool. Looking forward to seeing the detailed plan.

Ed - 0x1b, Inc.

unread,
Dec 5, 2011, 11:20:36 AM12/5/11
to trac...@googlegroups.com

yup - what he said +1

I am interested in seeing/helping Trac become fully semantic web enabled.

Ed

Grzegorz Sobanski

unread,
Dec 8, 2011, 8:11:41 AM12/8/11
to trac-dev
* Ian Wild <ian....@wandisco.com> [2011-12-02 13:42]:

> We plan to use Trac as a basis for a defect tracker supplied with our
> uberSVN product[2]. Our goal being to develop a tool which can compete
> out-of-the-box with other non-opensource defect trackers that have gained
> popularity in recent years.
[cut]

Aside from all the "community" issues described in proposal, I'm interested
in technical matters. Do you have a list of things you would like to change in
Bloodhound versus current Trac?
Do you only want to touch distribution and packaging, or also
functionality?

best regards
silk

Ian Wild

unread,
Dec 8, 2011, 12:01:35 PM12/8/11
to trac...@googlegroups.com
On Thu, Dec 8, 2011 at 1:11 PM, Grzegorz Sobanski <si...@boktor.net> wrote:
Aside from all the "community" issues described in proposal, I'm interested
in technical matters. Do you have a list of things you would like to change in
Bloodhound versus current Trac?

Hi Silk, 

During the last year we collected a list of improvements that we (and others we've spoken to) believe would make Trac better. Of course there's isn't much new there compared to the existing Trac wishlist / roadmap. Our view was always that we wanted to put time into building out some of these things (Multiproject support springs to mind for example).
 
Do you only want to touch distribution and packaging, or also
functionality?

Both. The packaging is important - installation experience and first impressions really count. I'm not saying the minimalist approach Trac takes is wrong, but it doesn't suit a busy person choosing a defect tracker and wanting to quickly evaluate and compare features, usability, functionality etc. 

So there will be effort spent on packaging, look and feel, and generally supplying a more complete product out of the box. There is plenty of functionality that we hope can be added within Bloodhound, some supplied by existing plugins whose authors we'd hope to work with and some needing to be written from scratch. Of course we're still in the planning period and nothing has been locked down regarding specific deliverables or a roadmap. I'd re-iterate that while WANdisco is leading this effort we don't plan to dictate the roadmap. It's a community project and these decisions will be made within an open group. 

Best Wishes, 

Olemis Lang

unread,
Dec 8, 2011, 12:14:17 PM12/8/11
to trac...@googlegroups.com
Hi everybody !
:)

On Thu, Dec 8, 2011 at 12:01 PM, Ian Wild <ian....@wandisco.com> wrote:
>
> On Thu, Dec 8, 2011 at 1:11 PM, Grzegorz Sobanski <si...@boktor.net> wrote:
>>
>> Aside from all the "community" issues described in proposal, I'm interested
>> in technical matters. Do you have a list of things you would like to change in
>> Bloodhound versus current Trac?
>
>
> Hi Silk,
>
> During the last year we collected a list of improvements that we (and others we've spoken to) believe would make Trac better. Of course there's isn't much new there compared to the existing Trac wishlist / roadmap. Our view was always that we wanted to put time into building out some of these things (Multiproject support springs to mind for example).
>
>>
>> Do you only want to touch distribution and packaging, or also
>> functionality?
>
>
> Both. The packaging is important - installation experience and first impressions really count. I'm not saying the minimalist approach Trac takes is wrong, but it doesn't suit a busy person choosing a defect tracker and wanting to quickly evaluate and compare features, usability, functionality etc.
>

[...]

... one question in the case of current Trac plugins , how will it
work the workflow involved in developing / adapting them ? Will they
still be developed in trac-hacks ... will the code be migrated onto
Bloodhound repository (separate from core components ... or not ) ? or
a separate extensions repository ? Or will it be a big-scale scenery
of what happens today with TracMercurial plugin inside Trac main SVN
repos ... AFAICS ?

PS: Thnx for your initiative and for supporting this effort .

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw

Featured article : Personalizando imagenes mostradas al compartir
páginas en sitios sociales
Get a signature like this. CLICK HERE.

Ian Wild

unread,
Dec 12, 2011, 11:42:42 AM12/12/11
to Olemis Lang, trac...@googlegroups.com
On Thu, Dec 8, 2011 at 5:14 PM, Olemis Lang <ole...@gmail.com> wrote:

... one question in the case of current Trac plugins , how will it
work the workflow involved in developing / adapting them ? Will they
still be developed in trac-hacks ... will the code be migrated onto
Bloodhound repository (separate from core components ... or not ) ? or
a separate extensions repository ? Or will it be a big-scale scenery
of what happens today with TracMercurial plugin inside Trac main SVN
repos ... AFAICS ?


Hi Olemis, 

There will need to be something of case by case approach to this. We'll be working closely with some of the plugin developers and where it makes sense and is possible we would like to re-license plugins to become a core part of the Bloodhound distribution. We also plan to be to work with Trac-hacks guys to develop some of the popular plugins there and there have been some really interesting ideas about how we could help that site develop.
 
PS: Thnx for your initiative and for supporting this effort .

The more discussions I have with people about this approach, the more comfortable I get that this is the right one for everyone involved. There is undoubtedly a lot of pent up demand for an Open Source defect tracker that Trac can meet, but doesn't out of the box. If we can take the elegance of the Trac architecture and combine it with a functional, attractive and well designed distribution then I'm confident this will have a big impact for users.  

Best Wishes, 

Ian

osimons

unread,
Dec 24, 2011, 10:14:41 PM12/24/11
to Trac Development
> uberSVN: Apache Subversion Made Easyhttp://www.uberSVN.com<http://www.ubersvn.com/>
>
> Everything you need to deploy Subversion in the Enterprisehttp://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite>
>
> Subversion communityhttp://www.svnforum.org


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.

First of all, Trac is BSD licensed open source software. Everyone is
free to use it and reuse it as they please - do anything except blame
us for any problems. Forks have happened before, and forks will no
doubt happen again. In that perspective the Bloodhound proposal is a
natural process.

As many of you know, I have sort of rolled my own distribution of Trac
too as the foundation for our hosted service. However, I've made my
modifications in custom plugins - adding to, changing, or removing
features via code and configuration. I've also contributed various
plugins and try to be involved in all the code that I actually use;
+95% of which is public. The version of Trac that I actually use is
pulled straight from the Edgewall repository, and I make no patches to
the Trac code. My decision all those years ago was to work with the
Trac project to improve it wherever time and ability allowed.

Bloodhound represents much the exact opposite of this, and it makes me
uncertain. It is uncertainty that may be unfounded once the project
gets going and we can see the actual plans, project activity and
interactivity between the project members. Then again it may not. I
won't be passing any judgement on the project for quite some time yet,
and from the outset my standpoint have been that if Bloodhound can
build a 'better Trac' I will not hesitate to use it.

I do find it strange that a fork is necessary before any work can
commence. I find it strange that none of the suggested Bloodhound team
have much association with Trac or plugins - I find some scattered
occurrences in mailing lists and tickets, but really not much code and
patches that I can find. However, good people can naturally make magic
happen regardless of what guidance history provides. I am sure they
can pull their weight and hit whatever goals the Bloodhound project
sets.

Which brings me back to actually describing the uncertainty I feel: A
full team of people going full speed ahead to achieve whatever goals
they set themselves in their new-founded community. As the proposal
also say, there will be a learning curve for them - learning Trac,
learning Trac development, and being educated in matters ranging for
compatibility, to i18n/l10n, existing plugins and various bits of
history that explain the rationale for decisions made (or not made)
because they were bad ideas (at least at the time). Growing that
knowledge in a community takes a lot of effort.

I will actually need to consider how I want to spend my own project
time. One part of me say very firmly that even though Bloodhound forks
the project, the decision to actually fork any code in non-compatible
ways should not be taken lightly. But if I spend my time supporting
the Bloodhound project and its developers via #trac IRC channel, open
mailing mailing lists, and tickets; what then becomes of my available
time for Trac project and plugins? I don't know. The other side of me
says to just let Bloodhound carry on as they please, and focus on what
matters to me now.

The wait-and-see approach can leave the Trac project standing and the
Bloodhound project standing, or perhaps one project succeed over time.
Or, the distinct possibility that neither project survives as already
thin resources are spread out across too many dimensions. Will the
users bother to keep on top of both projects? Will I as Trac and
plugin developer spend my time discussing what goes on at the
Bloodhound project whether I like to or not? When users start
reporting Bloodhound-related plugin bugs, that surely is a very
distinct possibility.

It is a shame that the project forks just because Apache Software
Foundation affinity is a hard requirement. I've seen all kinds of
discussions about forks in various projects over the years, but
forking the project without expressed commitment (or interest) from
any current core or plugin developer is something I can not remember
seeing before - at least not without a clear sense of direction. The
expected behavior would be to throw the handful of developers into the
existing project, and then fork if for some reason that does not work
out. All code would stay BSD, and according to proposal the project
could fork at any time and no one would be worse off. I just don't
understand why applying the effort outside the Apache umbrella would
have any less value to the corporate sponsors of the Bloodhound
project? The man-month applied on a feature branch now would be just
as valuable regardless of which public repository it was applied to,
would it not?

The Trac code (and most plugin code) is very free open source. From my
perpective there are no hard feelings about that at all. It is the
nature of the work we do and the licenses we work with. But, I could
still wish that the process and priorities had been different at the
forking end - or at least be made public in manner that is clear for
all to see.

My self-appointed role in the Trac project is being "champion" for the
needs of a stable, compatible, loosely-coupled system - a small core
that largely lives to support the plugin community and where everyone
if free to offer 'community distributions' that pick whatever parts
they need. My role thrive on activity by others so there are things
for me to evaluate, coordinate, guide, and adjust. It is a distinct
possibility that I will be sucked backwards into the Bloodhound -
primarily because 20 years of industry software project experience
(yes I'm that old) have really confirmed that I cannot keep my mouth
shut if I have an opinion to offer...

I would however like to hear more of the opinion of other Trac and
plugin developers about how you all envision supporting this
fragmented project structure. Are you prepared to switch your own
usage to the new project, and perhaps switch the main development of
your own plugins to a Bloodhound as a new base - or at least test
against it and provide the necessary compat abstraction if needed
across different versions in different projects? Or, put differently;
what is the level of success needed by Bloodhound before you are
prepared to make the effort - or even fully switch? One of the
expressed goals is to provide a "TicketSystem2" as 'the best defect
tracker on the planet'. Which is fine, but for that to happen pretty
much every Ticket-related plugin at Trac-Hacks.org will likely break -
it will need to be fixed, integrated, or forked. Have you all
considered what supporting 2 communities may involve?

The intention of this email was to describe my thoughts and
uncertainty. Currently I have a hard time believing that two vibrant
divergent communities can survive. In the end I think there can be
only one, but from 'now' until 'then' there will be much work to be
done. The decision I have to make is if I should walk into the
Bloodhound project facing forward, or decide to just ignore it and
look after my own things. But looking after my own things would to
some extent be a small dagger in the back of both projects making
either less likely to succeed. I don't consider myself a great
developer by any standards, but I know what I like and I know that
what I do makes a difference.

I positively hate the idea of providing feedback to a proposal that
have so little essence. I think Bloodhound project stated goals and
plans are wafer-thin from a software development standpoint. And,
judging from the Apache general incubator mailing list so far in
December there may be nothing more forthcoming for quite some time
either seeing plans would be for the new Bloodhound developer
community to decide. Whoever they may be, and whoever from us decide
to get involved. Which really brings the problem full circle.

I really wish the efforts were joined at the hip for now, and I'd have
no reason to feel uncertain about a fork if there were months of
preceding argument about project direction here at trac-dev. I would
be blatantly obvious that a fork was needed, costing what it may.
However, it is my firm belief that a software fork born out of
critical discussion between people that disagree, will be of much
better quality than a fork largely built by consensus in the offices
of a corporate sponsor.

People? Thoughts?



:::simon

http://trac-hacks.org/wiki/osimons
https://www.coderesort.com

Steffen Hoffmann

unread,
Dec 25, 2011, 10:32:17 AM12/25/11
to trac...@googlegroups.com
-----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-----

Ethan Jucovy

unread,
Dec 25, 2011, 10:55:32 AM12/25/11
to trac...@googlegroups.com
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. 

Greg Troxel

unread,
Dec 25, 2011, 11:01:06 AM12/25/11
to Ethan Jucovy, trac...@googlegroups.com

Ethan Jucovy <ethan....@gmail.com> writes:

> 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.

I've been a user since 2007, contributed only a few fixes to plugins,
but have been reading the list more or less. I also find the fork and
joining-apache notion a bit boggling. I don't mean to say I think ASF
is broken, but the present situation just feels very odd to me.


Rob Guttman

unread,
Dec 25, 2011, 11:30:34 AM12/25/11
to trac...@googlegroups.com
+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!

Ian Wild

unread,
Dec 25, 2011, 3:45:30 PM12/25/11
to trac...@googlegroups.com
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



--
Ian Wild
Director of Engineering
WANdisco, Inc.

Cell    : +44 (0)7961193722
Office DDI: +44 (0)114 3030472

http://www.wandisco.com

uberSVN: Apache Subversion Made Easy

Andy Baker

unread,
Dec 25, 2011, 3:54:28 PM12/25/11
to trac...@googlegroups.com
My $0.02? It smells a bit.

On the face of it WANdisco could be a force for good, but even if you
trust who they are now, can you trust who they might be in a years
time? Do they even know? Commercial organisations can come in with the
very best of intentions, but the world (and people) move on.

I fully endorse the "take the open source for free; buy the support"
model but it just makes me twitchy when people jump in like this. Call
me an old woolly *nix liberal, but something just sticks in the
throat. I guess in the same kinda way I'm now postgres not mysql,

My background is a cut'n'shut CVS/Subversion/Mantis/Trac. I confess
I've contributed little back to Trac other than the odd bugfix and
occasional comment on the usergroup but I suspect I'm like many back
seat drivers around here who would speak up and fight if it came to
it.

FWIW!
Andy

Felix Schwarz

unread,
Dec 25, 2011, 4:02:49 PM12/25/11
to trac...@googlegroups.com

Am 25.12.2011 21:54, schrieb Andy Baker:
> On the face of it WANdisco could be a force for good, but even if you
> trust who they are now, can you trust who they might be in a years
> time? Do they even know? Commercial organisations can come in with the
> very best of intentions, but the world (and people) move on.

Well, that's one of the things which are handled by the Apache software
foundation. The source is still free software and with the Apache License
there is even a limited patent protection clause. If WANdisco looses interest
in Bloodhound, the project still lives as long as there are other contributors
(which is one of the explicitely stated goals of the Apache proposal).

My biggest concern with Bloodhound currently (from a Trac perspective) is the
license incompatibility as it won't be possible to incorporate code from
Bloodhound into Trac (AFAIK all new code will be Apache-licensed).

fs

Andy Baker

unread,
Dec 25, 2011, 4:26:21 PM12/25/11
to trac...@googlegroups.com
Frankly I've been using the "seasonal break" to catch up on these
things so my take on the situation is knee jerk and buckshot at best;
only read about this an hour ago! (forgive me I've been off in
Drupal-land recently arguing about Trac/Drupal integration <yawn>).
Just felt a burning desire to stick my oar in.

This may be a stupid idea, so feel free to shoot me down in flames
people, but is there an argument to set up a quick'n'dirty forum to
thrash these things out in the open air? Maybe it's just me, but I
struggle to keep track of mailing lists; web based or otherwise.

Ethan Jucovy

unread,
Dec 25, 2011, 4:37:03 PM12/25/11
to trac...@googlegroups.com
On Sun, Dec 25, 2011 at 3:45 PM, Ian Wild <ian....@wandisco.com> wrote:
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.

+1.  I think this is an excellent goal, and I think Trac is an excellent base upon which to build it.
 
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. 

Did these discussions with the Trac core developers happen on record?  I don't see any previous discussions about this on trac-dev or any of the other obvious forums.

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.

Frankly the very act of importing a copy of the Trac core codebase, relicensing it and rebranding it, and actively seeking out a community of contributors to that project -- including from the existing pool of Trac plugin developers -- seems unavoidably undermining, given the scarce resources of time and attention.

It seems like the ideal scenario would be for an organization like the ASF to provide the infrastructural and legal assurances for the Trac core as the Trac core, and for a commercial organization like WANdisco to build its products on top of that.  I understand that this isn't very far off from what's happening here, and I can certainly see how expedience might favor the solution you've arrived at.  But the particular details that diverge from that ideal (starting from a fork of the core code; apparently rebranding a combination of that core fork + a configuration of it; and the licensing issues) seem quite important.

I appreciate your intention to work on these questions with the Trac community going forward.  But this could easily devolve into a chicken-and-egg problem where the expedient solution ends up remaining in place and we end up with two codebases, two brands, two licenses, two communities and two "core design philosophies" for good.  To prevent that, I hope that we can quickly develop a clear picture of what roadblocks stand in the way of the ideal solution, and that there can be a clear and ongoing conversation about how we all might reach that end goal as the project develops.  As a Trac user, plugin author, and sometimes-evangelist, seeing an effort to develop that particular roadmap up front -- on both the technical and nontechnical (e.g. legal and governance) sides -- would alleviate a lot of my fears about this effort and make me much more inclined to get involved.

Ian Wild

unread,
Dec 25, 2011, 5:53:01 PM12/25/11
to trac...@googlegroups.com
On Sun, Dec 25, 2011 at 9:37 PM, Ethan Jucovy <ethan....@gmail.com> wrote:

Did these discussions with the Trac core developers happen on record?  I don't see any previous discussions about this on trac-dev or any of the other obvious forums.

Although there was nothing inherently private about the discussions, they were predominantly held by email and a number of conference calls. At that time we were in a discovery mode and there were other commercial entities engaged in the same discussions. It wouldn't be appropriate for me to republish those threads verbatim, but I don't think there was anything controversial or that won't be / hasn't been repeated here. 

Frankly the very act of importing a copy of the Trac core codebase, relicensing it and rebranding it, and actively seeking out a community of contributors to that project -- including from the existing pool of Trac plugin developers -- seems unavoidably undermining, given the scarce resources of time and attention.

I understand the argument, but I don't believe thats what will happen. I can imagine that Apache Bloodhound might result in new life for some plugins, or even the contribution of new ones, but I just don't believe the efforts will be conflicting or negative to the Trac base. If the Apache incubator succeeds in growing a strong new community for Apache Bloodhound it will almost certainly serve to strengthen the Trac code and plugins too. It's too early to talk about specifics, but there are plenty of precedents with positive outcomes from similar situations. 
 
It seems like the ideal scenario would be for an organization like the ASF to provide the infrastructural and legal assurances for the Trac core as the Trac core, and for a commercial organization like WANdisco to build its products on top of that.  I understand that this isn't very far off from what's happening here, and I can certainly see how expedience might favor the solution you've arrived at.  But the particular details that diverge from that ideal (starting from a fork of the core code; apparently rebranding a combination of that core fork + a configuration of it; and the licensing issues) seem quite important.

This was our original suggestion. Somewhat understandably, because we hadn't been involved with Trac development previously, the view was 'you are free to do what you wish, but we will wait and see'. Trac as a project has longevity, users, reputation and plenty to keep it doing what it's doing. The good thing about this approach is that the proposal doesn't impact the course the existing Trac leadership is steering but the options remain open in terms of future developments.  
 
I appreciate your intention to work on these questions with the Trac community going forward.  But this could easily devolve into a chicken-and-egg problem where the expedient solution ends up remaining in place and we end up with two codebases, two brands, two licenses, two communities and two "core design philosophies" for good.  

Completely agree - it would be helpful to discuss this further. If we end up in a place where there's a conflict between the communities then something went wrong. Would there be interest in an open telephone conference in the new year to discuss these things in more detail? Maybe it's just me, but with so much to talk about, I find email a rather difficult medium to work with. 

Andy Baker

unread,
Dec 25, 2011, 6:04:56 PM12/25/11
to trac...@googlegroups.com
Amen the email comment and the open discussion, but the conference
call suggestion doesn't work for the community (IMO). Notwithstanding
the need to get all interested parties together at the same time, the
last time I tried an online WANdisco conference thing I was excluded
because I wasn't running Windoze (Cisco conf system). Doesn't fill me
with confidence.

Ian Wild

unread,
Dec 25, 2011, 6:29:07 PM12/25/11
to trac...@googlegroups.com
Very true, it can be difficult to organise such calls. It was just an idea to get things moving anyway. Even a smaller call which doesn't attempt to represent everyone can still be effective at progressing things.

Agree with you on Gotomeeting btw - It finally now supports OSX, but as a long time Ubuntu desktop user myself it's a bit of a fail. I guess the marketing team can't find anything better.

Ian

Greg Troxel

unread,
Dec 25, 2011, 6:49:52 PM12/25/11
to Ian Wild, trac...@googlegroups.com

Ian Wild <ian....@wandisco.com> writes:

> Agree with you on Gotomeeting btw - It finally now supports OSX, but as a
> long time Ubuntu desktop user myself it's a bit of a fail. I guess the
> marketing team can't find anything better.

Asking people in the open source community to use proprietary tools to
interact is just broken. If you can't figure out a 100% open source
conferencing solution, then you just don't do it - rather than saying
the proprietary tools are the best available. I was asked, as a
maintainer of an entirely unrelated free software project, to be on a
"conference call" using non-free tools - and I simply declined to
participate. (Expecting people that you pay for their time to use
non-free tools is another matter; I'm talking about people in a free
software community that don't owe you anything.)

Christian Boos

unread,
Dec 25, 2011, 7:01:25 PM12/25/11
to trac...@googlegroups.com
Hello

Simon, I hope you won't mind me quoting only the last bit of your mail,
it contains many other interesting points and I'll probably have a
second answer to elaborate on other aspects of it, but I'd like to first
clear a misconception that I've found in the last paragraph of your mail.

On 12/25/2011 4:14 AM, osimons wrote:
> I really wish the efforts were joined at the hip for now, and I'd have
> no reason to feel uncertain about a fork if there were months of
> preceding argument about project direction here at trac-dev. I would
> be blatantly obvious that a fork was needed, costing what it may.
> However, it is my firm belief that a software fork born out of
> critical discussion between people that disagree, will be of much
> better quality than a fork largely built by consensus in the offices
> of a corporate sponsor.
>

That's not exactly how it happened. Rather, "we" (cboos, rblank, jonas)
suggested the fork as the best way to get things moving forward for
WANdisco. Back in April (2011), they were talking about committing one
or two full-time developers to Trac, and as Remy and me got less an less
time for the project (as everyone could see), we were simply afraid that
our limited capacity of reviewing would be a bottleneck for them. Ok,
considering the very limited amount of contributions they produced so
far, our fears may now seem exaggerated ;-) Anyway, this could still
happen, as they're possibly still into an exploratory phase where
nothing from their side is yet public, so the model still holds: from
our point of view, their fork is potentially just an "external branch"
where they can evolve at their own speed and that we will try to review
at our pace and reintegrate whenever it makes sense. So why an external
branch, and not just a "sandbox" branch, you may ask? This indeed has to
do with politics and David Richards from WANdisco made it quite clear
early on that he was a bit concerned with the somewhat fuzzy status of
Edgewall and that he was much more comfortable sponsoring work under the
umbrella of Apache (so mostly for trademarks and IP concerns, IIUC).
From our side, we felt more comfortable to stick with the informal
Edgewall ways rather than switching to the more bureaucratic Apache
ways. Redoing the work on the infrastructure was not something
especially appealing either, given that after years of patient work we
finally reached a quite satisfying state. And again, before deciding a
move, we wanted to be sure it would be worth it and for that we needed
to "see" something happen.

So the way Ian explained what happened was indeed quite accurate:

On Dec 2, 1:41 pm, Ian Wild <ian.w...@wandisco.com> wrote:
>> As some of you may already be aware, earlier this year WANdisco[1]
>> approached members of the Trac development community with a view to working
>> out how we could most effectively invest development time into the project.

>> ...


>> The resulting discussions were interesting and culminated in the idea that
>> we might get the most done in the shortest time by performing a 'friendly
>> fork' of Trac and running that as a separate FOSS project. It was felt this
>> would present the least risk for everyone involved while still leaving
>> options open for future collaboration.

However we didn't say they should start with incubating an Apache
project. That was their call, and at this level I somehow share the
concerns about the risks of possible fragmentation of the community.
Starting with a new project like that may send the signal that they're
taking the Trac code base as it stands today and taking it somewhere
else (where? "as the community says"; but as there's not yet a community
for Bloodhound, there seem to be a bootstrapping issue there ;-) ).

Also there seem to be some discrepancy between the following reassuring
statements from Ian:

>> I want to be clear that our intention is in no way to undermine the current
>> Trac project and the progress that is making. We hope there can be
>> mutual collaboration and a shared journey. This approach gives us both the
>> freedom to continue with our own strategies while allowing us all to stay
>> engaged with each other and to achieve what I'm sure all of us desire - To
>> make Trac the best defect tracker on the planet.

and the wording of the Bloodhound proposal, which rather indicate a
"take over" approach:

- in the "Rationale" [1]:
>>> the current Trac development community is small and reluctant to
accept outside contributions.

Opinions here could diverge, but IMHO that's blatantly wrong. As any
project we're reluctant to accept marginally useful features or
unfinished code, but there's no shortage of good patches and good
contributions from non-committers which have been integrated. Not to
mention this is a bit strong of a statement coming from a party which so
far proposed no code contributions.

And by the way, committer status on Edgewall is usually granted after
seeing enough actual good patches from the contributor and a
demonstrated interest to the project, not when someone says "hey, this
project looks remotely interesting to me, I have no idea if I can or
will contribute but count me in" (slight caricature of an actual
self-appointment as a Bloodhound committer, recently seen in
gen...@incubator.apache.org - any parallel with sOme Other Apache
incubator project would certainly be seen as a stretch ;-) ).

>>> Given the Foundation�s reputation for building and maintaining
communities, we feel a new project, based on Trac but incubated under
the Apache umbrella, would help re-build the developer community, jump
started by developer time donated by WANdisco

"Re-build the developer community" rather than participate, expand or
similar...

- in the "Community" [2]:
>>> The current developers and supporting institution have moved on to
other things, and this has caused stagnation in the existing community.

Grr... we're not yet dead, and... we'll be back! :-)


I think we could continue at length to discuss how things could or
should work out, but from my side I'll take a very pragmatic approach:
if I see good stuff on the Bloodhound side, I'll probably propose to
take it back in t.e.o; if there are simply too many good things coming
from their side, we will probably regularly integrate their code
wholesale or possibly even "join" Bloodhound at some point in the
future; if there's only little activity or things that we don't like, we
will just continue our business as usual...

Nothing that dramatic, there are much bigger issues to tackle, like the
fact that the Trac model is progressively being dragged into the margin
by the advent of the likes of Github, Bitbucket and other Google Code...

-- Christian

[1]
http://wiki.apache.org/incubator/BloodhoundProposal?action=recall&rev=7#Rationale

[2]
http://wiki.apache.org/incubator/BloodhoundProposal?action=recall&rev=7#Community

Andy Baker

unread,
Dec 25, 2011, 7:02:19 PM12/25/11
to trac...@googlegroups.com
Bit of a shocker Ian, OS proponent company can't find OS conferencing
solution '-) I had to send people down to your conference in person to
try and make sense of where you were going. Was it Heathrow last year?
Still, bless 'em, they brought me a t-shirt.

I hear the "getting things moving" and I'm cool with that, but who
gets left behind as you move things on? I dunno, you may have a hard
core cabal already and us part timer's will just have to go with the
flow or fork ourselves (no pun intended).

Needs to be a bit more open for my liking.

Andy Baker

unread,
Dec 25, 2011, 7:05:14 PM12/25/11
to trac...@googlegroups.com
May have been mentioned already (email threads are impossible) but has
anyone raised the agile42 thing?

Remy Blank

unread,
Dec 25, 2011, 7:26:15 PM12/25/11
to trac...@googlegroups.com
osimons wrote:
> The intention of this email was to describe my thoughts and
> uncertainty.

Let me start by saying that I share most of Simon's concerns and open
questions.

Let me also give some more history about how it all came to the current
state, from the perspective of a Trac developer. Christian was contacted
privately by WANdisco on April 12th, about integrating Trac into a new
product of theirs. I was CCd on Christian's reply, and have been
involved in the discussions since then, as have all active core Trac
developers, through e-mail and 1:1 phone calls.

The discussions remained private because that's how we were contacted,
and we did suggest moving them to more public channels, which was
finally done by Ian Wild on December 2nd. In retrospect, we should have
moved to trac-dev much earlier, but as usual, hindsight is 20/20.

From very early on, WANdisco has been pushing for moving the Trac
project to the Apache Software Foundation. It seems that they were
worried about the somewhat fuzzy relationship between Trac and Edgewall
Software, and feared that the latter could interfere at some point. They
also mentioned its being an advantage for building a strong community.
This push was so strong, it kind of eclipsed the technical discussion,
of which there was very little.

The discussion more or less died at the end of May, and we haven't heard
much until the announce of Bloodhound in December.


Now for the more subjective part. Like many open-source projects, Trac
has always considered contributions based on their technical merit. So
you can imagine that we were a bit suspicious when WANdisco came in,
talking big about future contributions, asked for moving the project to
a different guidance and infrastructure, and proposed to add massive
manpower to the project (and by massive, I mean "much more than what the
current core developers can devote to the project", which is, granted,
very little).

So we suggested putting the move to the ASF on hold for the moment, and
to review the question after a few months of collaboration. We also
suggested the "friendly fork" variant as a way to avoid being a
bottleneck for contributions, as both Christian and myself had (and
unfortunately still have) very little time to spend on Trac. That's
where the discussions stopped.

So WANdisco went ahead and submitted their proposal to the ASF as a
first step. I still find this quite a heavy first step, but I guess
there were good reasons for that. I had really meant "friendly fork"
rather as "clone the Mercurial or Git mirror" than "re-license, re-brand
and re-import the whole project into the central Apache repository", but
I guess there's not really that much of a difference.

About fragmenting the community, the move to the ASF seems to me like
having more risk than a more light-weight approach, but TBH I have too
little experience with open-source projects in general to judge. From a
purely technical perspective, I believe it will be difficult to keep
compatibility between Trac and Bloodhound from the plugin perspective
for long, unless it's a major priority of WANdisco. It's already
difficult to make a plugin compatible with several major Trac releases,
let alone with diverging codebases. So I suspect plugin authors will
have to either choose their platform, or maintain separate (diverging)
branches.

As for myself, well, I guess Ian's "wait and see" quite accurately
describes my current position. I suspect that I will be more at ease in
a purely fun-driven project than a project that is partially driven by
the need to make money for at least one major participant, but I'm open
to changing my mind. For the moment, it will be business as usual in
Trac. If anything can be brought back from Bloodhound into Trac, great.
If not, that's ok, too. What I'm not going to do is duplicate my
efforts, and I wonder how many plugin authors will have the same thought.

-- Remy

signature.asc

Andy Baker

unread,
Dec 25, 2011, 7:47:55 PM12/25/11
to trac...@googlegroups.com
Awesome. Stupidly I'd entirely not thought about the plugin side.

As brilliant as the Trac core is, it is just that; a core. It is,
forgive me, worthless in the real world without the plugins. I'm an
end user of the product but even the basic build recipe always has
half a dozen plugins delivered as standard.

Remy Blank wrote:
> .. For the moment, it will be business as usual in


> Trac. If anything can be brought back from Bloodhound into Trac, great.
> If not, that's ok, too. What I'm not going to do is duplicate my
> efforts, and I wonder how many plugin authors will have the same thought.

Hard to argue with that.

Felix Schwarz

unread,
Dec 26, 2011, 5:59:07 AM12/26/11
to trac...@googlegroups.com

Am 26.12.2011 01:05, schrieb Andy Baker:
> May have been mentioned already (email threads are impossible) but has
> anyone raised the agile42 thing?

What's the "agile42 thing"? And no, it hasn't been mentioned so far.

fs

Benjamin Lau

unread,
Dec 26, 2011, 6:47:24 AM12/26/11
to trac...@googlegroups.com

I think that's referring to:
http://agilosoftware.com/

They produced a modified version of trac tuned for "agile" process.  If I remeber correctly they added some facility for manging stories (use cases if you don't know agile terminology).  Hadn't heard much about it in a few years.  Was evaluating it for a previous employer... We opted to roll our own solution on top of trac.

Ben

Felix Schwarz

unread,
Dec 26, 2011, 8:44:29 AM12/26/11
to trac...@googlegroups.com

Am 26.12.2011 12:47, schrieb Benjamin Lau:
> I think that's referring to:
> http://agilosoftware.com/

I'm aware of agile42 and Agilo (as was one of the previous developers) but I'm
unsure how this is related to the WANdisco approach now?

fs

Christian Boos

unread,
Dec 26, 2011, 5:05:08 PM12/26/11
to trac...@googlegroups.com
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...@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

Christian Boos

unread,
Dec 26, 2011, 5:53:54 PM12/26/11
to trac...@googlegroups.com
On 12/25/2011 10:02 PM, Felix Schwarz wrote:
> My biggest concern with Bloodhound currently (from a Trac perspective) is the
> license incompatibility as it won't be possible to incorporate code from
> Bloodhound into Trac (AFAIK all new code will be Apache-licensed).
>

AFAICT, there's no license incompatibility.

We have a 3-clause BSD license, which is acceptable for Apache, so they
don't need to change the license for the initial code base or for later
updates coming from t.e.o. Indeed, they plan to place only the new code
they'll be writing under ALv2, as Greg Stein wrote in [1].

If we want to take Bloodhound code into Trac, I don't see any problem
either, as the ALv2 explicitly allows redistribution of the code even
under a different license ("You may distribute the result under a
different license, but you need to acknowledge the use of the
Foundation's software", from [2]). So if we do so, we'll just need to
say something like "contains code from Apache Foundation" at some
appropriate place.

-- Christian

[1]
http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCABD8fLXs%2BCz3qQkR20bS2%2BSAW0N3yiTGkTH7iTxGwTUUwTADSQ%40mail.gmail.com%3E

[2] http://www.apache.org/foundation/license-faq.html#Distribute-changes

Manuel Jesús Recena Soto

unread,
Dec 26, 2011, 6:20:10 PM12/26/11
to trac...@googlegroups.com
Hi,

2011/12/26 Christian Boos <christi...@free.fr>:

A note, also we have Clinker Virtual Appliance [1] with Subversion,
Trac, Nexus, Sonar and Jenkins.
There is also Clinker Cloud [2].

[1] http://clinkerhq.com/products#va
[2] http://clinkerhq.com/products#cloud

Regards,

> --
> 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+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.
>

--
Manuel J. Recena Soto
* www.manuelrecena.com[/blog]
* www.linkedin.com/in/recena
* rec...@gmail.com
* +34 609710280 (ES)

Olemis Lang

unread,
Dec 27, 2011, 1:04:08 PM12/27/11
to trac...@googlegroups.com
I found Odd Simons (and other people ;)'s comments very interesting so here
you have my own $0.02 version . Firstly I say that I enjoy when people say
to me things like <<you're so damn wrong that it hurts>> , so please don't
hesitate to do so if you feel it's necessary . I write this by assuming
I'm terribly wrong and consult my personal psycho because I have butterflies
inside my head ;) .

Secondly , there are a few facts involved in this story :

- Wandisco has decided to launch some services and products. As a consequence
  a decision has been made that Trac should/will be the starting point to
  achieve product/service goals .
  * This means that continued and stable product support, defect resolution,
    ... are needed so as to ensure quality, reliability, ... and (I'm guessing)
    commitment so as to obtain some return-on-investment considering resources
    planned to be dedicated to this effort .
  * For some reason the current state of Trac community does not satisfy
    these requirements (... and honestly I understand this position ; e.g.
    the fact that Trac-Hacks is still running 0.10 , XML-RPC is
    disabled , etc, and nothing can be done even if some people want to, that's
    a bit frustrating for me - and this is not to blame anybody in particular,
    that's a fact and just an example - )
- The initial offer sent by the company to trac-dev & trac-users MLs was not
  received as they expected (for further details please consult previous
  comments).
- For some reasons (previous experience, ... whatever) ASF alignment seems to
  be a very important (non-technical?) decision

The fact that Wandisco still wants to consider Trac as the starting point to
achieve some goals (disregarding the other details involved) is positive
AFAICT . The fork of the project is, in part, a consequence of
aforementioned conflict of interests . The duplicate effort and overhead will
follow, but there are some technical and non-technical decisions that might
mitigate the impact on both projects ; as long as they both will be able
«coexist peacefully» (<= I hope you understand what I mean ) so that
maybe maintaining plugins for Bloodhound &
Trac will be similar to maintaining Trac plugins for 0.10 , 0.11 , 0.12 & 0.13 .

I do believe that it would be very important if both projects are in synch and
consider compatibilty as a goal to survive in this cruel world . Maybe a clear
workflow (policy , ... or whatever name you want to use ;) to exchange code
back and forth might help. I don't know what will happen in a near future but
there's still a chance to make this happen just like many other software
hosted by social coding sites (e.g. Bitbucket, Github ...) where many users
(in this case Wandisco , Trac-dev community , maybe others later ... who knows?)
commit changes to their (personal) repositories or patch queue repository and
notify each other (e.g. by sending push/pull requests, patches under version
control, ... whatever) of changes for review, approval, etc . Apache vs BSD
should not be a problem .

Another fact is that some plugin developers (please add my name to the list)
have no chance to dedicate time to develop Trac plugins . Myself , I have a
very long TODO list of enhancements , and I have not developed anything
related to Trac since long time ago, even if I'd liked to, because I really
cannot dedicate time to this (ok ... shame on me). The offer to
support full-time Trac/Bloodhound developers IMO is positive as well AFAICS .
I hope you agree if I mention that there's still a lot of place for enhancement
in Trac core and plugins , e.g. testing and related QA, OS-specific packaging
and more.

AFAICS (and I may be wrong) this is happening nowadays in many
open-source projects, even if **circumstances are not always the same** . I'll
mention some of them :

- Mercurial is a well established FLOSS project ... there you have Google
  maintaining a custom branch of development to make it run on top of their
  Big Table & Co. infraestructure.
- Subversion is another paradigmatic FLOSS project . Once again there you have
  many companies building cutomized Subversion distributions (including
  Google & Wandisco) and paying developers (including Google & Wandisco) to
  make the project move forward .
- Trac itself has been customized , patched , packaged & distributed in many
  forms ... e.g. Bitnami , OForge , Sourceforge as a hosted app , Assembla ...
  and project is still alive (although this is a completely different story).
- Ubuntu & Debian ... a love story ;)
- The Linux kernel vs patched kernels (e.g. Red Hat's ? , SuSE's ?)
- OTOH other projects e.g. Hudson have been forked (e.g. Jenkins) and both of
  them survive and were able (as far as I could see in the ML ...) to
  <<move the wheel together>> while still keeping their own identity.

Well I really cannot dedicate more time to write .
I look forward to your comments as well , hoping this initiative will
be positive for
both Trac & Bloodhound

--
Regards,

Olemis

Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw

Featured article : Personalizando imagenes mostradas al compartir
páginas en sitios sociales
http://feedproxy.google.com/~r/simelo-news/~3/nSdht_RqLKk/personalizando-imagenes-mostradas-al.html
Tweet: +1 RT @holdenweb This is insane. Everyone should be fighting
this: Stop American Censorship http://t.co/S9EIkYdk #fb
Follow @olemislc Reply Retweet   23:08 Dec-14
  Get this email app!
Get a signature like this. CLICK HERE.

anatoly techtonik

unread,
Dec 28, 2011, 4:25:43 AM12/28/11
to trac...@googlegroups.com
There is an opinion that WANdisco tries to gain market share by pretending they are the major driving force behind the open source communities that support projects like Subversion and Trac. But in case of Trac the marketing efforts can be wasted, because IIUC none of WANdisco employers have a trail of commits to Trac core. So, the best way to build up a "reputation" is to place WANdisco members name on the official page of Apache Software Foundation with Trac and Apache logos and a new project name announcement. And then include this new project name in all marketing materials.

The strategy that hurts an ecosystem.

Nothing prevents WANdisco from contributing back to Trac, but they didn't and probably don't want to, so I believe the true motives are somewhat different from the goals of community.

Somebody said that there is no time to review changes from Wd members. This problem can be solved without Apache projects and all that buzz. First, Wd can stash the changes much like everyone else does and just remove them from their own branch when the changes are merged. It's just a matter of coding culture and maturity of company processes to be able to do so. Second, it could speed up the review process by compensating time of Trac core developers without buying and restricting them to be a flag bearers of Wd. There is a legal entity - Edgewall Software, that's year after year supported this project (unlike Wd), so nobody would really object if you could try to cooperate with them first instead of jumping into your own public project and calling for everyone to move.
-- 
anatoly t.

Felix Schwarz

unread,
Dec 28, 2011, 6:28:43 AM12/28/11
to trac...@googlegroups.com

Am 28.12.2011 10:25, schrieb anatoly techtonik:
> There is an opinion that WANdisco tries to gain market share by pretending
> they are the major driving force behind the open source communities that
> support projects like Subversion and Trac. But in case of Trac the marketing
> efforts can be wasted, because IIUC none of WANdisco employers have a trail of
> commits to Trac core. So, the best way to build up a "reputation" is to place
> WANdisco members name on the official page of Apache Software Foundation with
> Trac and Apache logos and a new project name announcement. And then include
> this new project name in all marketing materials.
>
> The strategy that hurts an ecosystem.

Sorry but I think that this conclusion is unfounded and does WANdisco wrong.
From my talks with them I have the impression that they really like to drive
an open source trac forward.

Also there is at least Mat Booth which has a bit of Trac experience.

> Somebody said that there is no time to review changes from Wd members.

That was cboos+rblank, the two most knowlegable Trac developers. I guess we
should trust them with the assessment.

> There is a legal
> entity - Edgewall Software, that's year after year supported this project
> (unlike Wd),

Is Edgewall still operating? My impression is that it is inactive and all Trac
developers are employed by other companies/self-employed. Also you can't
seriously compare the Apache Foundation with a tiny company.

And last but not least it's not only about a legal entity but also about
Apache being a foundation which won't turn around and leave which is possible
for any commercial entity.

In the end I have to say that your post is unfounded and partly unfair to
WANdisco - probably it just came around the wrong way due to the nature of email.

fs

Felix Schwarz

unread,
Dec 28, 2011, 6:45:16 AM12/28/11
to trac...@googlegroups.com

Am 26.12.2011 23:53, schrieb Christian Boos:
> If we want to take Bloodhound code into Trac, I don't see any problem either,
> as the ALv2 explicitly allows redistribution of the code even under a
> different license ("You may distribute the result under a different license,
> but you need to acknowledge the use of the Foundation's software", from [2]).
> So if we do so, we'll just need to say something like "contains code from
> Apache Foundation" at some appropriate place.

Not sure if that's true.

"Even if you change every single line of the Apache code you're using, the
result is still based on the Foundation's licensed code. You may distribute


the result under a different license, but you need to acknowledge the use of

the Foundation's software."
http://www.apache.org/foundation/license-faq.html#Distribute-changes

Probably it's just my English but I'm not sure if the 'You may distribute the
result under a different license' applies only to the previous sentence ("if
you change every single line of the Apache code").

The paragraph says also:
"I've made improvements to the Apache code; may I distribute the modified result?

Absolutely -- subject to the terms of the Apache license, of course. (...)
Just remember that the original code is still covered by the Apache license
and you must comply with its terms."

However I assume that's a pretty easy question for Apache's laywers so we can
just wait for their correct(tm) interpretation.

fs

Dirk Stöcker

unread,
Dec 28, 2011, 9:32:39 AM12/28/11
to trac...@googlegroups.com
On Wed, 28 Dec 2011, Felix Schwarz wrote:

> On 28.12.2011 10:25, Anatoly Techtonik wrote:
>> There is an opinion that WANdisco tries to gain market share by pretending
>> they are the major driving force behind the open source communities that
>> support projects like Subversion and Trac. But in case of Trac the marketing
>> efforts can be wasted, because IIUC none of WANdisco employers have a trail of
>> commits to Trac core. So, the best way to build up a "reputation" is to place
>> WANdisco members name on the official page of Apache Software Foundation with
>> Trac and Apache logos and a new project name announcement. And then include
>> this new project name in all marketing materials.
>>
>> The strategy that hurts an ecosystem.
>
> Sorry but I think that this conclusion is unfounded and does WANdisco wrong.
>> From my talks with them I have the impression that they really like to drive
> an open source trac forward.
>
> Also there is at least Mat Booth which has a bit of Trac experience.
>
>> Somebody said that there is no time to review changes from Wd members.
>
> That was cboos+rblank, the two most knowlegable Trac developers. I guess we
> should trust them with the assessment.

I'm not the big Trac developer, as Trac is only a tool I need to manage my
current main software, but still I agree with Anatoly, that the way it is
presented currently seems strange to me.

If WANdisco would have done major changes and improvements or even lots of
ticket fixes and the patches would have been ignored for a long time, then
I would agree something is wrong and a fork probably necessary.

But although I'm not really happy with the progress of Trac I can't blame
Trac maintainers for ignoring patches. They ignore bug reports (a logical
effect due to missing resources), but the don't ignore provided help.

So I doubt the motives of a fork are really positive.

The proper way would be to participate and help driving Trac into future.
When during this process development is moved to other servers and
maintaining is done mainly by WANdisco then this seems fine to me.

> Is Edgewall still operating? My impression is that it is inactive and all Trac
> developers are employed by other companies/self-employed. Also you can't
> seriously compare the Apache Foundation with a tiny company.
>
> And last but not least it's not only about a legal entity but also about
> Apache being a foundation which won't turn around and leave which is possible
> for any commercial entity.

Actually I don't understand why "company" should be better. I do both
commercial software development and open source and most of the time the
open source projects (when at least minimal successful) have much higher
quality than everything commercials are able to produce. Software
development does not need a company behind. The last 20 years showed this
clearly.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Christian Boos

unread,
Dec 28, 2011, 1:34:21 PM12/28/11
to trac...@googlegroups.com
Hello Anatoly,

While I can understand your concerns, hostility will bring us nowhere,
so please try to keep an open mind ;-)

On 12/28/2011 10:25 AM, anatoly techtonik wrote:
> There is an opinion that WANdisco tries to gain market share by
> pretending they are the major driving force behind the open source
> communities that support projects like Subversion and Trac.

They indeed are one of the major contributors for Subversion (sponsoring
Greg and employing Hyrum, AFAIK).

> But in case
> of Trac the marketing efforts can be wasted, because IIUC none of
> WANdisco employers have a trail of commits to Trac core. So, the best
> way to build up a "reputation" is to place WANdisco members name on the
> official page of Apache Software Foundation with Trac and Apache logos
> and a new project name announcement. And then include this new project
> name in all marketing materials.
>
> The strategy that hurts an ecosystem.
>
> Nothing prevents WANdisco from contributing back to Trac, but they
> didn't and probably don't want to, so I believe the true motives are
> somewhat different from the goals of community.

Well, they made their true motive clear enough, no need to search for an
hidden agenda. They want to try to build a JIRA competitor and selected
Trac as the starting point, then hope that having one or two full time
paid developers plus an emerging Apache-based community will do the
rest. There's of course no guarantee that this strategy will work (and
during the first "private" rounds of discussion I think I did my best to
draw their attention to the various risks this implied), but they
nevertheless want to try it out, so let's just hope we can get a
positive outcome from this initiative. I imagine that at the very least
those full-time developers will manage to produce some interesting
changes that we, hobbyist developers, could learn from ;-) And then
maybe not, we'll see.

>
> Somebody said that there is no time to review changes from Wd members.
> This problem can be solved without Apache projects and all that buzz.
> First, Wd can stash the changes much like everyone else does and just
> remove them from their own branch when the changes are merged. It's just
> a matter of coding culture and maturity of company processes to be able
> to do so.

Remember that they're Subversion proponents, so the fork/merge mentality
of DVCs is not exactly part of their culture [1], which I find curious
because it's just a natural extension to the "don't be afraid of
conflicts" motto inherited from CVS [2] (but I digress...)

> Second, it could speed up the review process by compensating
> time of Trac core developers without buying and restricting them to be a
> flag bearers of Wd. There is a legal entity - Edgewall Software, that's
> year after year supported this project (unlike Wd), so nobody would
> really object if you could try to cooperate with them first instead of
> jumping into your own public project and calling for everyone to move.

This didn't work out for various reasons, and no matter how you look at
it, it's hard to imagine that any kind of sponsorship / compensation
would go without influencing the technical decisions we could make (e.g.
what if we were wanting to put svn and git at the same support level as
optional components under tracopt?).

-- Christian

[1] http://blogs.wandisco.com/2008/07/17/what-a-git/
[2]
http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge

John Hampton

unread,
Dec 28, 2011, 2:08:32 PM12/28/11
to trac...@googlegroups.com
On Wed, Dec 28, 2011 at 3:45 AM, Felix Schwarz <felix....@oss.schwarz.eu> wrote:
"Even if you change every single line of the Apache code you're using, the
result is still based on the Foundation's licensed code. You may distribute
the result under a different license, but you need to acknowledge the use of
the Foundation's software."
http://www.apache.org/foundation/license-faq.html#Distribute-changes

Probably it's just my English but I'm not sure if the 'You may distribute the
result under a different license' applies only to the previous sentence ("if
you change every single line of the Apache code").

Of course, the standard IANAL disclaimer applies, however, as one that does have a good grasp of English, the "Even" at the beginning of the sentence gives credence to Christian's interpretation.  It implies that once can change all the code, but need not to.  The amount of code that changes in this case is irrelevant.  One line, all lines, or any number of lines, The result is still based on Foundation code.  Said result can then be redistributed under another license as along as one "acknowledges the use of Foundation software".

This is how I would expect a normal, native English speaker to interpret the paragraph above.
 
-John

Ethan Jucovy

unread,
Dec 30, 2011, 5:14:07 PM12/30/11
to trac...@googlegroups.com
I've posted a response to the proposal on the Apache Incubator list:


As I said earlier in this thread, I'm all for more Trac distributions, but between the significant unresolved questions about community interactions, license compatibilities, and how to ensure this project remains symbiotic with Trac; the proposal's misrepresentations about the Trac community's procedures; and the lack of any clear, specific statements to date as to why Bloodhound must resort to a fork, I think this project would be much more likely to succeed and to have a healthy relationship with Trac if these issues are addressed before it moves forward.

-Ethan

Christian Boos

unread,
Dec 30, 2011, 6:27:43 PM12/30/11
to trac...@googlegroups.com


Well, the vote was already closed the 22th of December and Bloodhound is
now "incubating"
(http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAJjMeYPPbzC_-mcE8uB0sp6...@mail.gmail.com%3E).

It will nevertheless be instructive to read the answers to your post.

-- Christian

Dirk Stöcker

unread,
Dec 30, 2011, 6:53:49 PM12/30/11
to trac...@googlegroups.com
On Sat, 31 Dec 2011, Christian Boos wrote:

> Well, the vote was already closed the 22th of December and Bloodhound is now
> "incubating"
> (http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCAJjMeYPPbzC_-mcE8uB0sp6...@mail.gmail.com%3E).
>
> It will nevertheless be instructive to read the answers to your post.

It is a bit strange to make decisions without counting the opinion
of affected people in their own communication system (i.e. this
mailinglist).

osimons

unread,
Dec 30, 2011, 7:13:37 PM12/30/11
to Trac Development
On Dec 30, 11:14 pm, Ethan Jucovy <ethan.juc...@gmail.com> wrote:
> I've posted a response to the proposal on the Apache Incubator list:
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbo...
>
> As I said earlier in this thread, I'm all for more Trac distributions, but
> between the significant unresolved questions about community interactions,
> license compatibilities, and how to ensure this project remains symbiotic
> with Trac; the proposal's misrepresentations about the Trac community's
> procedures; and the lack of any clear, specific statements to date as to
> why Bloodhound must resort to a fork, I think this project would be much
> more likely to succeed and to have a healthy relationship with Trac if
> these issues are addressed before it moves forward.

Wow Ethan. I'm in awe. Really.

I had the Bloodhound discussion @ incubator mailing list bookmarked so
whenever I revisited I found no new posts. I figured the Apache
Incubator discussion had died down for the holiday, and would pick up
in the new year. I did not notice the pager appearing in the archives
at some stage (how dumb can users be!), so the mails with votes +
result on page 2 was unseen by me when I wrote the "uncertainty post"
that sparked this new round of discussion. If I had seen it, I may not
have posted figuring this was over-and-done with. I am glad I did
write, as this thread certainly is a testament to the interest that
Trac still has in the community.

Your summary is extremely accurate and well-documented. There is one
minor "OR" that need not be in there: As to my knowledge none of the
private communication included demands for Trac commit privileges.
Taking Trac to Apache was a hard requirement from the start, and at no
point did WANdisco express any interest in working with the Trac
community in its current form. Either move us, or replace/duplicate
us.

I hope the Apache Incubator & Bloodhound uses this information to
build a better project. Now that they have given life, I certainly
hope they can make the effort to spread some meat onto its thin
bones...


:::simon

http://trac-hacks.org/wiki/osimons
https://www.coderesort.com


osimons

unread,
Dec 30, 2011, 7:57:14 PM12/30/11
to Trac Development
On Dec 31, 12:53 am, Dirk Stöcker <t...@dstoecker.de> wrote:
> On Sat, 31 Dec 2011, Christian Boos wrote:
> > Well, the vote was already closed the 22th of December and Bloodhound is now
> > "incubating"
> > (http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CC AJjMeYPPbzC_-mcE8uB0sp6coVWjvCLVB+W9zkyxsKvPXLi...@mail.gmail.com%3E).
>
> > It will nevertheless be instructive to read the answers to your post.
>
> It is a bit strange to make decisions without counting the opinion
> of affected people in their own communication system (i.e. this
> mailinglist).

Well, up until the conclusion of the vote all publicly expressed
sentiment on this mailing list was some variation of "cool, good luck"
- which is the Trac community's default positive response to anyone
wanting to invest time and resources to work with Trac in any form. We
are very naive in that respect, but then again we can afford to seeing
we are not players in any form of corporate or foundation power play.

Nor is it our responsibility to feed the Apache incubator mailing list
with reason or discussion - it is not our project and they are grown-
ups that make their own decisions, for good or bad. If anyone at
Apache Incubator level had any uncertainly about the information
provided or felt it needed verification or more details, surely they
would just have asked someone? Anyone aware of Trac development would
be able to provide pointers to people to poke for information, and any
one of us would gladly offer our advice.

Their software foundation, their incubator, their proposal, their
project. They got to figure this out.

Ian Wild

unread,
Dec 30, 2011, 9:16:53 PM12/30/11
to trac...@googlegroups.com
On Sat, Dec 31, 2011 at 12:13 AM, osimons <odds...@gmail.com> wrote:
Your summary is extremely accurate and well-documented. There is one
minor "OR" that need not be in there: As to my knowledge none of the
private communication included demands for Trac commit privileges.
Taking Trac to Apache was a hard requirement from the start, and at no
point did WANdisco express any interest in working with the Trac
community in its current form. Either move us, or replace/duplicate
us.


That is inaccurate.

Our first discussions involved the active Trac committers along with many others previously involved in the project. Our goal was to sponsor as many full time developers as possible to work on the existing Trac project and build something significantly more substantial in terms of appeal and functionality. It was not until later that we were made aware of the current status of Edgewall as a shell company with no employees and no revenue. It was then we highlighted that for the level of investment we are making we would need proper governance and infrastructure in place to support the project. Suggesting the use of an opensource Software foundation wasn't immediate and was not the only option, although it does have many merits[1] that made it appealing.

If Ohloh[2] is to be believed, in the last 12 months the number of committers contributing more than single digit number of changes to Trac has been three, with the vast majority of the commits being entered by Christian or Remy. That may hide other contributions, but the fact remains that Trac as a project needs a head of steam if it is to get to a position where it could become recognized as a leading issue tracker again. Perhaps that goal isn't shared by everyone here, which is fine, but that's certainly what Apache Bloodhound is aiming to do.  

Unfortunately, no one from the initial group we contacted was able to commit to working on Trac full time (or even part time afaik). Since then we have been able to employ a number of experienced Python developers who are familiar with the Trac architecture and who will be dedicated to the project. I can assure people that the view so far is very much in favour of maintaining compatibility with Trac and even the idea of forking or not is certainly still open to discussion within the Apache Bloodhound community.  

I truly hope none of this has to degenerate into a slanging match. I believe our goals are broadly aligned and I'll state again that we aren't here to undermine the Trac community of today and I simply don't believe we will. The existing approach and ethos has value and there is no reason anything has to change here if you guys don't want it to. I'm really happy to be involved in this discussion and I think we can address all of the points made if they haven't been already (It seems questions like licensing have been, even if some people missed those answers). Given the public Apache Bloodhound mailing list is to be launched very shortly, I think most of my input into the discussion of the plans will be best made there and of course anyone is welcome to participate in that too.

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


DavidRichards

unread,
Dec 30, 2011, 9:24:44 PM12/30/11
to Trac Development
Hi everyone. I'm David from WANdisco.

I've just read some of the posts here and I think it's worth just
clarifying a couple of points.

1. If a corporation, such as WANdisco, wanted to take control of an
open source project then the *last* place to do it would be as part of
the ASF (Apache Software Foundation). For those not familiar with the
ASF I would recommend reading this http://www.apache.org/foundation/how-it-works.html.

Henrik Ingo wrote a very interesting piece (http://openlife.cc/blogs/
2010/november/how-grow-your-open-source-project-10x-and-revenues-5x)
last year about successful open source projects. Henrik concludes "an
obvious recommendation that vendors participating in open source
development and business, should look into participating in
collaborative community developed projects - where the standard and
familiar governance form is a non-profit foundation. If a vendor is
currently in control of an open source project, it should explore the
option of transferring the project to an existing foundation, or
alternatively creating its own foundation for it. Since the original
vendor is always the strongest candidate to become the leading vendor
also in a collaboratively developed project, the vendor could, as a
rule of thumb, expect this strategy - if properly executed - to result
in a 10x growth in the project and product, but also 10x larger
addressable market, of which the vendor can expect to capture 50% or
more as its own market share."

2. Apache 2.0 is a *very* permissive license. Quoting Apache "The
goals of this license revision have been to reduce the number of
frequently asked questions, to allow the license to be reusable
without modification by any project (including non-ASF projects), to
allow the license to be included by reference instead of listed in
every file...The result is a license that is supposed to be compatible
with other open source licenses, while remaining true to the original
goals of the Apache Group and supportive of collaborative development
across both nonprofit and commercial organizations."

A number of (inaccurate) comments related to license compatibility
have been posted here so I think it's worth reading the Apache 2.0
license FAQ. The FAQ on the license can be found here:
http://www.apache.org/foundation/license-faq.html

But the key to understand the legalese is:

I'm not a lawyer. What does it all MEAN?
Describing legal documents in non-legalese is fraught with potential
for misinterpretation. Notwithstanding the text that follows, the
actual text of the license itself is legally binding and
authoritative.

That said, here's what the Apache license says in layman's terms:

It allows you to:

freely download and use Apache software, in whole or in part, for
personal, company internal, or commercial purposes;

use Apache software in packages or distributions that you create.

It forbids you to:

redistribute any piece of Apache-originated software without proper
attribution;

use any marks owned by The Apache Software Foundation in any way that
might state or imply that the Foundation endorses your distribution;

use any marks owned by The Apache Software Foundation in any way that
might state or imply that you created the Apache software in question.

It requires you to:

include a copy of the license in any redistribution you may make that
includes Apache software;

provide clear attribution to The Apache Software Foundation for any
distributions that include Apache software.

It does not require you to:

include the source of the Apache software itself, or of any
modifications you may have made to it, in any redistribution you may
assemble that includes it;

submit changes that you make to the software back to the Apache
Software Foundation (though such feedback is encouraged).

3. Prior to embarking on the Bloodhound effort we did talk to
Christian and Remy on several occasions. They are great guys. They do
the vast majority of the development effort on Trac today. But it's
pretty difficult with only 2 active developers - that is *not* a
criticism by the way. Priorities change and people move on to other
things. Ohloh have a decent view on the stats: http://www.ohloh.net/p/trac

Because of this and the fact that Edgwall's current status is "fuzzy"
we decided that our contribution should be as part of a larger,
independent entity. In addition our experience of Subversion in an
ASF context has been extremely positive. Our open source Subversion
developers only develop Subversion. The same will apply to Apache
Bloodhound.

4. We did extensive research and we really like Trac. Obviously or we
wouldn't be embarking on a project based on Trac right? We do have a
belief that the core should be a little larger than it is today and
some 'key' plug-ins should be included. We also believe it should
support multiple projects. I realize that having a larger core does
conflict with some businesses out there where the proprietors are
solving the problem of keeping "close track on all development and
issues for all the components you use to run the system... 10+
components often with monthly release cycles."

5. The reason for the friendly-fork? During discussion with Edgwall
this was a suggested approach. It's not negative, in fact the
assumption was that a friendly-fork would be well received by a
community looking for improvements to multi-project support and other
things. I guess the important thing here is that this is a *friendly*
fork and this was a suggested approach.



I will conclude by saying that the Apache Bloodhound project will be
open to anyone to participate. To again quote the ASF "We firmly
believe in hats. Your role at the ASF is one assigned to you
personally, and is bestowed on you by your peers. It is not tied to
your job or current employer or company."

The next step for us is to build a great product and community. We
are not competing with Trac or anything else for that matter. Our
goal is simple. Build the best defect tracker in the world.

My only request here is to stick with facts and try to avoid
scaremongering. Ian Wild, WANdisco's head of engineering is happy to
answer any questions any of you may have. Remy & Christian have
answered your quesries pretty well in this thread and I would strongly
urge you to use them as the 'go-to guys' from Trac.

happy new year everyone!

- David Richards
President & CEO, WANdisco

Felix Schwarz

unread,
Dec 31, 2011, 4:43:53 AM12/31/11
to trac...@googlegroups.com
Hi David,

thanks for your input here.

Am 31.12.2011 03:24, schrieb DavidRichards:
> 2. Apache 2.0 is a *very* permissive license. (...)

Unfortunately I think you miss the point of the licensing issues from the Trac
side. Of course Apache is very liberal and it wouldn't be a problem for Trac
to depend on a Apache-licensed package.

IMHO the question is if Trac can take an Apache-licensed file (for example)
and put it in Trac, distributing it under the terms of the BSD license and not
under the Apache license (though with acknowledgement + the original source in
the original repo is still Apache of course).

From my naive understanding this requires the right to relicense which no free
software license gives you (unless you're the copyright owner).

Otherwise Trac is licensed under 'BSD + Apache' (most files under BSD, some
Apache) which effectively makes it 'Apache' for the complete source code (as
it is nearly impossible to deal with licensing on a file/hunk level). Also
this is a pain when comes to license auditing: different licenses within the
same body of source code are a great mess unless you pick the most restrictive
license and assume the whole code is under that license (e.g. Apache+BSD code
in GPL software -> assume GPL for every file and you won't violate the
Apache/BSD licenses).

Probably I'm too picky here but I still hope we can get an Apache laywer's
input with a clear answer to the question :-)

Ian Wild

unread,
Dec 31, 2011, 6:44:51 AM12/31/11
to trac...@googlegroups.com
On Sat, Dec 31, 2011 at 9:43 AM, Felix Schwarz <felix....@oss.schwarz.eu> wrote:

Probably I'm too picky here but I still hope we can get an Apache laywer's
input with a clear answer to the question :-)

Hi Felix, 

I don't think Greg Stein will mind me quoting him as an authoritative voice on the subject (Greg is a Vice Chairman of Apache and very experienced in this area). He was involved in some of the original discussion in May and answered a question along the same lines:
> Regarding the use of the Apache license I'm a bit skeptical. Since Trac
> (core) is 100% BSD, it wouldn't make much sense in accepting non-BSD
> code contributions. But I'm not a lawyer, maybe there's ways around that...

The Apache License, v2, is compatible with BSD and GPLv3. It is a
permissive license, like BSD, but has been modernized to account for
the explicit rights under current copyright law. It also deals well
with patents and incidental contributions from people. IOW, same
philosophy, but tighter language.

Should the decision be to create a "friendly fork", then carrying
changes back and forth will still allow the overall package to be
delivered under a permissive license. It is simply that parts will be
BSD and parts will be ALv2.

The choice of ALv2 is pragmatic: should the code end up at the ASF,
then using ALv2 will be mandatory for the overall package (and the ASF
allows incorporating BSD into the package).

I hope that helps, but would be happy to answer more questions and
concerns about licensing.

Cheers,
-g

I believe this clarifies things sufficiently? This is a pretty well trodden path and the bottom line is that it is possible for Trac to keep distributing under a BSD license while incorporating Apache licensed code if thats how it pans out. 

Best Wishes, 

Ian

Dirk Stöcker

unread,
Dec 31, 2011, 7:15:46 AM12/31/11
to trac...@googlegroups.com
On Sat, 31 Dec 2011, Ian Wild wrote:

> I believe this clarifies things sufficiently? This is a pretty well
> trodden path and the bottom line is that it is possible for Trac to keep
> distributing under a BSD license while incorporating Apache licensed
> code if thats how it pans out.

Actually it says Trac either needs to switch to Apache license or
cannot use any code from the fork. This is the opposite of what you say.

As Felix already said, maintaining license on file level is impossible and
also would prevent structures or functions to be copied - normally patches
do not consist of singular files.

Ian Wild

unread,
Dec 31, 2011, 7:50:07 AM12/31/11
to trac...@googlegroups.com
On Sat, Dec 31, 2011 at 12:15 PM, Dirk Stöcker <tr...@dstoecker.de> wrote:
Actually it says Trac either needs to switch to Apache license or cannot use any code from the fork. This is the opposite of what you say.

"Carrying changes back and forth will still allow the overall package to be delivered under a permissive license. It is simply that parts will be BSD and parts will be ALv2."

Where does that say that Trac would need to switch to an Apache license to use code licensed under ALv2?

As Felix already said, maintaining license on file level is impossible and also would prevent structures or functions to be copied - normally patches do not consist of singular files.

Assuming the Trac project wants to take Apache Bloodhound code, why is shipping the Apache v2 license file and adding an appropriate attribution in the form of a boilerplate to any file that contains Apache licensed code 'impossible'? 

The Apache FAQ[1] provides a clear understanding of this to me. Perhaps you could restate exactly where the confusion is coming from?

Best Wishes, 

Ian

Dirk Stöcker

unread,
Dec 31, 2011, 7:55:29 AM12/31/11