On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding <field...@gbiv.com> wrote: > On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: > >> On Jan 7, 2012 4:24 PM, "Roy T. Fielding" <field...@gbiv.com> 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. -Hyrum [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 http://www.uberSVN.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
