On Jan 9, 2012, at 9:42 AM, Hyrum K Wright wrote: > 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.)
Yes, that is a common side-effect of introducing a sense of awareness to a project that is otherwise in stasis. I have no doubt that Trac needs new blood and a driving force capable of energizing the community that developed on top of it. >>> What you have is a vocal minority that disagree. Ethan is not even a core >>> committer, as far as I can tell. It isn't a vocal minority. Not a single person outside of WANdisco considered it a good idea. Not one. Yes, most of the people commenting were the implementers of plug-ins, but they are also supposed to be part of the Bloodhound proposal. >>> >>> 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." I don't follow that. Is Edgewall still a formal organization capable of owning copyright? If not, who owns the copyright? Have Christian and Remy stopped all work on Trac, or are they just busy with their $jobs? And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. Yes, there are many reasons to prefer that it is under the ASF. Many, many, many reasons. That doesn't change the fact that Apache only accepts voluntary contributions. Before you import code to the ASF, you have to get some indication from the authors that they either *want* us to maintain that code or that they have completely abandoned it. Not just a sigh and a statement that the BSD license is forkable -- they have to want Apache to build a community for maintaining that code. Otherwise, we don't, for social reasons that have little to do with licensing. >>> 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. Those sound like the goals for a commercial distribution of an open source project. In any case, there is no evidence that it cannot be done on trac-dev because it wasn't attempted. > 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. There is no Bloodhound community, Hyrum. There is one company with a few employees ready to start producing a unified distribution of what is currently some other group's work product. And I don't see how you can say that the Trac community is philosophically opposed to one direction or another when you haven't been discussing it in public. > 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. I would agree that, if there was some evidence of sustained contribution in a direction that is being blocked by the existing Trac community, then such a block would make for the basis of a community fork. However, that has not even been attempted yet, and we don't do those forks at Apache. If someone wants to fork a community here, they have to start with only the code that they own or that has been deliberately submitted to the ASF as contributions. Just to be clear, if WANdisco had approached one of the ASF's projects in the same way, suggesting significant changes in our decision-making process before making any significant contributions of their own, we'd tell them to piss off. Actually, that would be the polite translation. It is not a measure of the project's "activity" or "philosophy". It is a measure of the respect we have for non-contributors who want to tell us how to build software. ....Roy --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
