incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyrum K Wright <>
Subject Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Date Mon, 09 Jan 2012 17:42:39 GMT
On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding <> wrote:
> On Jan 7, 2012, at 1:49 PM, Greg Stein wrote:
>> On Jan 7, 2012 4:24 PM, "Roy T. Fielding" <> wrote:
>>> ...
>>> The original developers are not ambivalent to this fork.
>> Untrue. Christian and Remy are, and always have been, supportive. They were
>> the ones to suggest the fork, rather than trying to make the changes in
>> trunk.
> I read the trac-dev mailing list.  To say that they are supportive is a huge
> stretch of the imagination.  They are sadly resigned to see a potential
> contributor decide to fork the code instead of working with them directly.
> And the rest of the community (which is far larger than the core) thinks
> the idea stinks.

If you read trac-dev, you will also notice that the discussion about
the so-called "fork" has more responses than all other threads in the
last three months *combined*.  Lots of navel gazing, not much work.
(Though surprisingly, discussion *has* picked up in the past couple of
weeks, so maybe this is a Good Thing all around.)

>> What you have is a vocal minority that disagree. Ethan is not even a core
>> committer, as far as I can tell.
>> Edgewall, the copyright holder, is a defunct shell. That is a primary
>> reason WANdisco wanted to move to the ASF: a home with actual backing and
>> longevity.
> Then we should be able to convince Christian and Remy to join the initial
> committers list and bring the rest of the TRAC community with them.
> Why has that not been done?

It has been.  They have essentially said "we've moved on, best of luck."

>> WANdisco has definite problems in how they approach and work with open
>> source communities. They discussed this stuff with the Trac principals
>> privately, rather than with the broader community. But my read is that the
>> Trac leads are supportive of Bloodhound.
> They are supportive of people doing work on Trac.  They did not support a
> fork at the ASF.  What they told WANdisco was that, rather than come to some
> artificial agreement on how they should work together before WANdisco
> had contributed anything, that WANdisco should fork the code and start by
> making contributions.  That's it.  The only reason that Christian has not
> directly opposed Bloodhound is because he believes the BSD license gives
> permission to fork the code.
>> My interest here is seeing Trac revitalized, improved, and delivered as an
>> awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS)
>> Jira. I like the Google Code tracker, but I'm biased there :-P
> There is no evidence to suggest that cannot be done on trac-dev.

I'm not sure I agree with this statement.  Trac has a singular and
well-defined philosophy built around a small core and an environment
of plugins.  This isn't the place to debate the merits of that
architecture, but suffice it to say that such a system can often
require a lot of work to get to a usable state.

The goals of Bloodhound are separate from that: create a full-featured
issue tracker which is easy to deploy and use for end users and
administrators both.  Honestly, Trac is a good product, and is an
excellent choice as the core for Bloodhound, but the community goals
differ.  Significantly.

Bloodhound won't happen on trac-dev because the Trac community is
philosophically opposed to the direction the nascent Bloodhound
community wants to take.  That's okay: people are allowed to have
different goals.  And the great part about open source is we all don't
have to reinvent the wheel to implement those different views of the
world.  Bloodhound can be a derivative of Trac with its own community
and goals [1].  There's room enough in the world for them both.

I think the Trac community sees this as a zero-sum game: if people are
contributing to Bloodhound, they *aren't* contributing to Trac.
"Instead, we should try to convince the Bloodhound people that our
philosophy is best, and they should just come over here."  Resolving
such philosophical differences and technical goals is difficult at
best, and I don't see it happening soon.  But that's okay, there isn't
a globally optimal solution to issue tracking, and we can agree to
experiment with different paths.

But I've probably said too much already.  There isn't much more I can
add here, and the last think I want to do at this point is prolong the
agony of this discussion.


[1] Indeed, I know of at least one private proprietary derivative of
Trac, but since it's proprietary, nobody knows about it and nobody
complains.  It's the fact that Bloodhound is proposed as open source
which is causing the hullaballoo in the first place.


uberSVN: Apache Subversion Made Easy

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message