You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Hyrum K Wright <hy...@wandisco.com> on 2012/01/01 00:35:39 UTC
Re: [VOTE] Bloodhound to join the Incubator
Agreed: we don't (and shouldn't) encourage hostile forks at the ASF.
This isn't a hostile fork.
>From the beginning, the intention of Bloodhound has been to be to use
the existing Trac system as much as possible and to improve upon it.
After many private (and some public) conversations with several of the
Trac principals, it was agreed that the existing community had a
different set of goals than the Bloodhound supporters, and that a
separate community and derivative codebase was probably in the best
interests of all.
The Incubator proposal was publicized and discussed on trac-dev
*simultaneously* with the discussion on general@incubator, and the
reception was generally indifferent (as Greg mentioned earlier)[1].
While I don't discount Ethan's feelings out-of-hand, it certainly is a
bit late in the game to be re-raising these issues. Basically, I just
don't understanding the concerns that a very vocal minority appear to
have. Is it a problem with the license? Fracturing of the community?
Technical issues? Or just "don't take my code"?
As for discussion about the technical and other project direction, I'd
encourage interested parties to bring up their concerns and
suggestions on bloodhound-dev@incubator.apache.org. (Note: that list
is only a few days old, so it may take a little while for folks to get
subscribed.) Since one of the main goals of Bloodhound (and the
Incubator) is building community, and we should try as hard as
possible to get Bloodhound-related discussion on the bloodhound-dev@
list.
All that being said, if people are looking for any kind of closure on
this issue, they will probably have to wait a bit. The next few days
are holidays for a large part of the world, so any discussion will
likely attract a very vocal minority, biasing the resulting
discussion.
-Hyrum
[1] It interesting to note that the single thread on trac-dev
discussing Bloodhound has more posts than all other threads to
trac-dev during the last three months *combined*.
On Sat, Dec 31, 2011 at 9:57 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> I find this post disturbing. Had it been posted before the vote closed I most certainly would have voted -1 as we don't encourage hostile forks at the ASF.
>
> Ralph
>
> On Dec 30, 2011, at 12:30 PM, Ethan Jucovy wrote:
>
>> -1
>>
>> The Bloodhound proposal is to build an issue tracker by first importing the
>> Trac core code into the Apache Subversion repository. As currently
>> planned, this project has potential to be detrimental to the existing Trac
>> brand and community, and it seems that the Bloodhound project's goals could
>> equally be achieved without taking the heavy-handed first step of forking
>> the Trac codebase. I hope that the Bloodhound team will consider building
>> Bloodhound as a set of plugins and configurations and an installer that
>> distributes them with an upstream Trac version, rather than forking Trac as
>> a first resort.
>>
>> My concerns fall into three categories:
>>
>> a) The Bloodhound proposal contains substantial allegations about the
>> health of the Trac community and the competence of its maintainers, as
>> motivating factors for the "fork and rebuild community" approach proposed.
>> No documented evidence has been provided to support these claims, and many
>> of the claims are directly contradicted by the publicly available records
>> in the Trac community's issue tracker, mailing list archives and commit
>> logs.
>>
>> b) Neither the Bloodhound proposal nor the ensuing discussions have
>> demonstrated any compelling legal, procedural, technical or strategic
>> reason why Bloodhound should be based on a fork of Trac rather than an
>> upstream distribution of Trac.
>>
>> c) Although the people involved have been friendly and expressed a desire
>> to keep the two projects in cooperation, the actions taken so far and the
>> intentions announced are characteristic of a hostile fork.
>>
>> --
>>
>> (a) The Bloodhound proposal contains substantial allegations, without
>> evidence, about the health of the Trac community and the competence of its
>> maintainers. These allegations are largely contradicted by publicly
>> available records of the Trac community.
>>
>> * The Bloodhound proposal claims, "Private efforts to engage the existing
>> developers in implementing features have been negatively received[1]."
>>
>> (a.1) I was not involved, and all conversations between WANdisco and the
>> Trac developers were private and off-record, so it is impossible to verify
>> the actual sequence of events. But, per [2], it seems that what is
>> referred to here is the following: WANdisco’s developers asked for commit
>> access to the Trac core, and/or proposed migrating the Trac core to the
>> Apache Foundation’s infrastructure and governance, with no prior history of
>> engagement with the Trac community and no prior contributions (see a.2
>> below). If this is the case, characterizing it as an offer to "implement
>> features" which was "negatively received" by the Trac developers is
>> significantly misleading.
>>
>> (a.2) Five out of Bloodhound's six initial core developers have no publicly
>> documented history of attempting to contribute or engage with Trac's
>> existing mailing lists, issue tracker, or subversion repository[3,4,5,6,7].
>> The contributions of the one developer who has participated on the Trac
>> mailing list and issue tracker have been well received[8,9].
>>
>> * The proposal also says: "As discussed earlier, the current Trac
>> development community is small and reluctant to accept outside
>> contributions[1]." This last statement is false:
>>
>> (a.3) Outside contributions from non-core developers are certainly
>> accepted. A quick search of Trac’s issue tracker turns up at least six
>> patches submitted by non-core developers and merged in to core within the
>> past four months[10,11,12,13,14,15]. Other contributions like bug reports
>> and documentation are also accepted and well received.
>>
>> (a.4) Furthermore, outside contributors with a history of good submissions
>> are granted direct commit access. According to the Trac project wiki the
>> core currently has five active developers with wholesale commit
>> access[16]. Two of those developers became core committers in the past
>> year, based explicitly on their records of prior contributions[17,18].
>>
>> --
>>
>> (b) WANdisco's Ian Wild said that "We'd rather only fork what we have
>> to[19]" but neither the Bloodhound proposal nor the ensuing discussions
>> have demonstrated any substantial legal, procedural, technical or strategic
>> reason why Bloodhound should be based on a fork of Trac rather than an
>> upstream distribution of Trac.
>>
>> (b.1) Legal: On the trac-dev mailing list, in explaining WANdisco’s
>> decision to propose a fork, Ian Wild said, "The strong governance and very
>> important legal protections that the Apache Software Foundation provide are
>> not matched by the current Trac setup[20]." This may be true (I am not in
>> a position to judge) but as far as I understand, the "legal protections"
>> concern does not seem relevant to the decision to fork, one way or another.
>> IANAL, but it seems that precisely the same legal protections would be in
>> force for the Bloodhound project if its developers build upon an upstream
>> Trac distribution rather than forking it.
>>
>> My understanding is that the Apache Foundation is not in a position to hold
>> and enforce the Trac core's copyright without a Transfer of Copyright from
>> the current copyright holders, whether or not the code is forked into an
>> Apache repository. Therefore any copyright enforcement // brand protection
>> that the ASF can offer would only apply to new code in the Bloodhound
>> project, and not the initial Trac codebase upon which it is based.
>>
>> (b.2) Procedural: as described above (a.2, a.3, a.4) there is no reason to
>> believe that the Trac core team would reject contributions from Bloodhound
>> participants, and if Bloodhound participants provided consistently good
>> contributions faster than the core team could review them, there is
>> precedent for being granted commit access.
>>
>> (b.3) Technical: as the Bloodhound proposal says, Trac has "a pluggable
>> infrastructure, and is generally considered stable." Trac's component
>> architecture allows for a wide ecosystem of plugins and configurations to
>> extend Trac with custom data models, business logic, workflows, external
>> application integrations, and themes; that ecosystem is supported by the
>> Trac Hacks community website and mailing list as well as the trac-users
>> list. At least two installation packages[21, 22] and four other
>> custom distributions like Bloodhound exist or have existed[23] based on
>> upstream Trac releases without needing to fork.
>>
>> (b.4) Strategic: apparently the features that WANdisco wants to add to Trac
>> align well with the features already planned/desired by the Trac community
>> and Trac core team. WANdisco’s Ian Wild said, "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)[24]."
>>
>> --
>>
>> (c) WANdisco claims this is a friendly fork, but thus far their actions and
>> intentions demonstrate no credible commitment to ensuring that their
>> project remains symbiotic with Trac, and the discussions thus far in the
>> two communities already provide cause for concern.
>>
>> (c.1) In the Bloodhound thread on the trac-dev mailing list, Trac community
>> members have expressed concern that the project may detract from the Trac
>> brand, siphon away developer interest, or add maintenance burden for plugin
>> authors, documentation authors, and tech support. Bloodhound’s initiators
>> have not substantially addressed these concerns; their only response to
>> these concerns to date has been a "trust us // wait and see" attitude,
>> saying that "it's too early to talk about specifics" and an offer to set up
>> a conference call to discuss these issues in parallel with (rather than
>> blocking) the project's initiation and code migration as an
>> Apache-incubated project. WANdisco’s Ian Wild said [25]:
>>
>> "I understand the argument, but I don't believe thats what will happen. I
>> can imagine that Apache Bloodhound might result in new life [...] but I
>> just don't believe the efforts will be conflicting or negative to the Trac
>> base. [...] It's too early to talk about specifics, but there are plenty of
>> precedents with positive outcomes from similar situations."
>>
>> (c.2) At the same time, and contradicting these assurances (also
>> contradicting their claims about the size and viability of the Trac
>> community) the project initiators have specifically announced that their
>> initial strategy for community-building will be to siphon developers'
>> attention away from Trac to Bloodhound. The Bloodhound proposal states: "The
>> target audience for growing the developer community is the current Trac
>> user and developer communities." Other statements in the proposal[26] and
>> on trac-dev[27] confirm these intentions. While they are certainly welcome
>> gestures, the inherent contradiction between these intentions and
>> WANdisco’s assurances that their "intention is in no way to undermine the
>> current Trac project and the progress that is making[28]" suggests that the
>> project’s initiators do not have the required perspective to maintain a
>> symbiotic relationship regardless of their good intentions.
>>
>> (c.3) Considerable confusion remains over license compatibilities, both
>> whether BSD-licensed Trac code can be reused in the Bloodhound repository
>> and whether Apache-licensed Bloodhound code can be reintegrated into the
>> Trac repository. This has been a source of confusion on the trac-dev
>> Bloodhound thread recently with no authoritative resolution from an
>> expert[29, 30].
>>
>> (c.4) Significant discussion about the proposal and its ramifications have
>> occurred on the trac-dev list in the past few days, only after the
>> discussion and votes cast on the Apache Incubator list had died down.
>>
>> * Ian Wild announced on trac-dev that he would be submitting the Bloodhound
>> proposal on December 2
>>
>> * Ian Wild followed up to announce that the proposal had been submitted,
>> also on December 2
>>
>> * Between December 2 - 12 the trac-dev thread received 11 posts from 5
>> distinct authors
>>
>> * Greg Stein proposed a vote on the Apache Incubator mailing list on
>> December 15
>>
>> * Hyrum Wright linked to the "complete discussion" on the trac-dev thread
>> on the Apache Incubator list on December 15
>>
>> * Between December 24 - 28 the trac-dev thread[31] received an additional
>> 32 posts, from 17 distinct authors, many of which expressed concern,
>> suspicion or confusion.
>>
>> --
>>
>> In short: the Bloodhound proposal consists of incubating an open source
>> project by cloning the Trac codebase, developing a brand around this
>> potentially divergent codebase, implementing features already desired by
>> the Trac core developers, and building the team of contributors by drawing
>> interest from the existing Trac community. In evaluating the merits of
>> this proposal it seems essential to consider the accuracy of WANdisco’s
>> claims about the Trac community’s attitudes, viability, and governance; the
>> substance of the initiators' reasons for forking; and the publicly stated
>> opinions of the Trac community as to whether this will be seen as a hostile
>> fork. In addition, the proposal should not move forward without
>> satisfactory answers to the following questions:
>>
>> * The proposal states that the Trac development community "is small"
>> and "has largely dissipated," and that "a new project [...] would help
>> re-build the developer community." If Bloodhound's initiators believe
>> this, then why does their community-building plan seem to revolve around
>> reaching out to the existing Trac communities?
>>
>> * Does Bloodhound have any concrete community-building strategy that does
>> not consist of drawing from the existing Trac community in order to bolster
>> its fork?
>>
>> * How will the existence of Bloodhound not be a drain on the attention of
>> Trac core developers (watching features built in Bloodhound and potentially
>> taking the time to backport them); Trac plugin authors and maintainers
>> (being a divergent codebase to evaluate when deciding whether or not to
>> ensure compatibility); and users providing volunteer assistance in the Trac
>> mailing lists and IRC channel (adding an additional target
>> platform+configuration to field questions about)
>>
>> * Verifiably false statements about the Trac community's viability,
>> attitudes, and processes should be removed from the text of the Bloodhound
>> proposal; as should, preferably, subjective judgments and/or unfalsifiable
>> assertions in the same vein (e.g. "the development community surrounding
>> Trac has largely dissipated"; "very few commits to the source code
>> repository"; "stagnation in the existing community"; private off-record
>> offers of contributions "negatively received")
>>
>> * Authoritative resolutions by a neutral expert should be provided to the
>> questions of legal compatibility;
>>
>> * Specific, substantial explanations should be provided as to why a
>> pre-emptive fork -- of a stable, highly extensible project with an
>> established and continued history of accepting core contributions -- is the
>> only path forward;
>>
>> * and, if the "fork and rebuild" proposal stands, a clear, realistic
>> roadmap should be developed detailing specific actionable steps to be
>> undertaken which, if successful, would eliminate the specific, substantial
>> obstacles which necessitate a fork.
>>
>> --
>>
>> References:
>>
>> [1] http://wiki.apache.org/incubator/BloodhoundProposal
>>
>> [2] http://groups.google.com/group/trac-dev/msg/f70e92742bdba15b
>>
>> [3]
>> http://groups.google.com/group/trac-dev/search?group=trac-dev&q=gavin+mcdonald&qt_g=Search+this+group
>>
>> [4]
>> http://groups.google.com/group/trac-dev/search?group=trac-dev&q=mark+poole&qt_g=Search+this+group
>>
>> [5]
>> http://groups.google.com/group/trac-dev/search?group=trac-dev&q=hyrum+wright&qt_g=Search+this+group
>>
>> [6]
>> http://groups.google.com/group/trac-dev/search?group=trac-dev&q=john+chambers&qt_g=Search+this+group
>>
>> [7]
>> http://groups.google.com/group/trac-dev/search?group=trac-dev&q=gary+martin&qt_g=Search+this+group
>>
>> [8]
>> http://groups.google.com/group/trac-dev/search?group=trac-dev&q=mat+booth&qt_g=Search+this+group
>>
>> [9]
>> http://trac.edgewall.org/query?reporter=~matbooth&or&cc=~matbooth&or&owner=~matbooth&col=id&col=summary&col=owner&col=type&col=status&col=priority&col=milestone&order=priority
>>
>>
>> [10] http://trac.edgewall.org/ticket/10318
>>
>> [11] http://trac.edgewall.org/ticket/10322
>>
>> [12] http://trac.edgewall.org/ticket/10368
>>
>> [13] http://trac.edgewall.org/ticket/10377
>>
>> [14] http://trac.edgewall.org/ticket/10490
>>
>> [15] http://trac.edgewall.org/ticket/10493
>>
>>
>> [16] http://trac.edgewall.org/wiki/TracTeam
>>
>> [17]
>> http://groups.google.com/group/trac-dev/browse_thread/thread/560ed779f62d455b
>>
>> [18]
>> http://groups.google.com/group/trac-dev/browse_thread/thread/24bb9cdc4c458b79
>>
>>
>> [19] http://groups.google.com/group/trac-dev/msg/5dfc9284fa54cc08
>>
>> [20] http://groups.google.com/group/trac-dev/msg/b00884f5f6017d4a<http://groups.google.com/group/trac-dev/msg/b00884f5f6017d4a?>
>>
>>
>> [21] http://bitnami.org/stack/trac
>>
>> [22] http://clinkerhq.com/products#va
>>
>> [23] http://trac.edgewall.org/wiki/TracDerivatives
>>
>>
>> [24] http://groups.google.com/group/trac-dev/msg/9596d8067d0a4c35
>>
>>
>> [25] http://groups.google.com/group/trac-dev/msg/f49461665c99d691
>>
>>
>> [26] "Realizing that incubation is an opportunity to grow the community, we
>> plan to make every attempt possible to invite additional developers from
>> the existing Trac user and developer communities, including those involved
>> in plugin development." From
>> http://wiki.apache.org/incubator/BloodhoundProposal
>>
>> [27] "We'll be working closely with some of the plugin developers." From
>> http://groups.google.com/group/trac-dev/msg/b80211cf4a1b5d4f
>>
>> [28] http://groups.google.com/group/trac-dev/msg/2e7db6b2a588c0b5
>>
>>
>> [29] http://groups.google.com/group/trac-dev/msg/bb68b25cfb26930b
>>
>> [30] http://groups.google.com/group/trac-dev/msg/13f3e255a4f4c148
>>
>>
>> [31]
>> http://groups.google.com/group/trac-dev/browse_thread/thread/14268355c6e1d494/b00884f5f6017d4a#
>> for
>> the complete thread.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Ralph Goers <ra...@dslextreme.com>.
Thanks, Jukka.
What I find interesting is that most of the posts in the first thread are after the vote had already closed here and it seems apparent they weren't even aware the vote had taken place. From what I read there was a single initial comment expressing discomfort about the proposal that was answered with "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." which was responded to with "Cool. Looking forward to seeing the detailed plan."
As I read it the ambivalence then seemed to be a wait and see about what the detailed plan was to be. I'm having trouble reconciling the answer in [4] since the only thing it could be based on was that bit of discussion and what happened in private, from which it is clear to me that they believed a plan was going to be proposed before anything was going to happen, especially in light of the later comments. Even in the private discussion with the few that were involved there apparently was misunderstanding as they said they expected more of a git-fork rather than a community fork. That is hard to understand though, since all along they knew the proposal was to come to the ASF.
There is quite a bit of history in there about private discussions. Nothing seems to have been discussed in public with Trac until Dec 2, almost simultaneously with the proposal here.
So far, there has only been a single response to [2].
I've not come to any conclusion myself on this but at the moment I'm still uncomfortable.
Ralph
On Jan 1, 2012, at 3:34 AM, Jukka Zitting wrote:
> Hi,
>
> On Sun, Jan 1, 2012 at 12:35 AM, Hyrum K Wright
> <hy...@wandisco.com> wrote:
>> The Incubator proposal was publicized and discussed on trac-dev
>> *simultaneously* with the discussion on general@incubator, and the
>> reception was generally indifferent (as Greg mentioned earlier)
>
> To add some pointers to this, the trac-dev discussion thread is at
> [1]. A related vote was just called at [2].
>
> The question about the fork status was also brought up [3] on general@
> during discussion, and was IMHO answered pretty well [4].
>
> Obviously the fear of this being "seen as a hostile fork" did become
> reality at least for some, so I guess there's a lesson here for us
> all.
>
> [1] https://groups.google.com/d/topic/trac-dev/FCaDVcbh1JQ/discussion
> [2] https://groups.google.com/d/topic/trac-dev/kMVFq9pkfus/discussion
> [3] http://markmail.org/message/w5efz3m2ihs7gmbw
> [4] http://markmail.org/message/3ylvwqjmqqvvh3sf
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [VOTE] Bloodhound to join the Incubator
Posted by Greg Stein <gs...@gmail.com>.
"minimal activity" is the phrase I used. :-)
On Jan 3, 2012 2:49 AM, "Mark Struberg" <st...@yahoo.de> wrote:
> actually 6 commits in a month is not huge, but by far not nothing!
>
> We have projects here which have less commits per month...
>
> I wouldn't consider the Trac community dead.
>
>
> LieGrue,
> strub
>
>
> ----- Original Message -----
> > From: Niclas Hedhman <ni...@hedhman.org>
> > To: general@incubator.apache.org
> > Cc:
> > Sent: Tuesday, January 3, 2012 6:17 AM
> > Subject: Re: [VOTE] Bloodhound to join the Incubator
> >
> > On Tue, Jan 3, 2012 at 8:26 AM, Greg Stein <gs...@gmail.com> wrote:
> >> I think it important to highlight that trac-dev was notified on Dec 2
> >> of the Bloodhound proposal, but Ethan and others didn't even notice
> >> for three weeks. The activity level on trunk, and the active
> >> committers can be seen on Ohloh:
> >> http://www.ohloh.net/p/trac/contributors?sort=latest_commit
> >>
> >> Looking at the timeline on trac.edgewall.org, it seems many of the
> >> commits are release-related or possibly on dev branches. It is kind of
> >> hard to tell. Trunk is certainly minimal activity.
> >
> > The Ohloh account is set up against trunk/ [1] only, so it is fairly
> > straight forward;
> >
> > 30-Day Commit Activity
> > Dec 2 — Jan 1
> >
> > 3 committers made 6 commits
> > 15 files modified
> > 46 lines added
> > 11 lines removed
> >
> > And a
> > svn log http://svn.edgewall.com/repos/trac/trunk
> > gives you all the commits (why is this hard to tell?);
> > 217 commits during 2011. I am pretty sure that is higher than some
> > ASF projects.
> >
> > I am not putting any value to these numbers, just pointing to them on
> > Ohloh and their SVN repository.
> >
> >
> >
> > [1] http://www.ohloh.net/p/trac/enlistments
> >
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://www.qi4j.org - New Energy for Java
> >
> > I live here; http://tinyurl.com/3xugrbk
> > I work here; http://tinyurl.com/6a2pl4j
> > I relax here; http://tinyurl.com/2cgsug
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [VOTE] Bloodhound to join the Incubator
Posted by Mark Struberg <st...@yahoo.de>.
actually 6 commits in a month is not huge, but by far not nothing!
We have projects here which have less commits per month...
I wouldn't consider the Trac community dead.
LieGrue,
strub
----- Original Message -----
> From: Niclas Hedhman <ni...@hedhman.org>
> To: general@incubator.apache.org
> Cc:
> Sent: Tuesday, January 3, 2012 6:17 AM
> Subject: Re: [VOTE] Bloodhound to join the Incubator
>
> On Tue, Jan 3, 2012 at 8:26 AM, Greg Stein <gs...@gmail.com> wrote:
>> I think it important to highlight that trac-dev was notified on Dec 2
>> of the Bloodhound proposal, but Ethan and others didn't even notice
>> for three weeks. The activity level on trunk, and the active
>> committers can be seen on Ohloh:
>> http://www.ohloh.net/p/trac/contributors?sort=latest_commit
>>
>> Looking at the timeline on trac.edgewall.org, it seems many of the
>> commits are release-related or possibly on dev branches. It is kind of
>> hard to tell. Trunk is certainly minimal activity.
>
> The Ohloh account is set up against trunk/ [1] only, so it is fairly
> straight forward;
>
> 30-Day Commit Activity
> Dec 2 — Jan 1
>
> 3 committers made 6 commits
> 15 files modified
> 46 lines added
> 11 lines removed
>
> And a
> svn log http://svn.edgewall.com/repos/trac/trunk
> gives you all the commits (why is this hard to tell?);
> 217 commits during 2011. I am pretty sure that is higher than some
> ASF projects.
>
> I am not putting any value to these numbers, just pointing to them on
> Ohloh and their SVN repository.
>
>
>
> [1] http://www.ohloh.net/p/trac/enlistments
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/3xugrbk
> I work here; http://tinyurl.com/6a2pl4j
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Jan 3, 2012 at 8:26 AM, Greg Stein <gs...@gmail.com> wrote:
> I think it important to highlight that trac-dev was notified on Dec 2
> of the Bloodhound proposal, but Ethan and others didn't even notice
> for three weeks. The activity level on trunk, and the active
> committers can be seen on Ohloh:
> http://www.ohloh.net/p/trac/contributors?sort=latest_commit
>
> Looking at the timeline on trac.edgewall.org, it seems many of the
> commits are release-related or possibly on dev branches. It is kind of
> hard to tell. Trunk is certainly minimal activity.
The Ohloh account is set up against trunk/ [1] only, so it is fairly
straight forward;
30-Day Commit Activity
Dec 2 — Jan 1
3 committers made 6 commits
15 files modified
46 lines added
11 lines removed
And a
svn log http://svn.edgewall.com/repos/trac/trunk
gives you all the commits (why is this hard to tell?);
217 commits during 2011. I am pretty sure that is higher than some
ASF projects.
I am not putting any value to these numbers, just pointing to them on
Ohloh and their SVN repository.
[1] http://www.ohloh.net/p/trac/enlistments
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Ralph Goers <ra...@dslextreme.com>.
FWIW, this link was used by Sam during the discussion I referred to below - http://s.apache.org/QeN
Ralph
On Jan 2, 2012, at 11:29 PM, Ralph Goers wrote:
>
> On Jan 2, 2012, at 11:15 PM, Greg Stein wrote:
>
>> On Jan 2, 2012 10:51 PM, "Ralph Goers" <ra...@dslextreme.com> wrote:
>>>
>>> Greg, I do not care one bit how much commit activity happens at Trac. As
>> long as there is some kind of active community it is improper to fork it
>> without their permission.
>>
>> Eh? You ever read the "rules for revolutionaries" page? The basic concept
>> is: don't try to force two communities into one; when separate visions for
>> the project occur, then separate them.
>>
>> I don't see it as our place to *judge* communities. If it is a fork, or a
>> corporate spin-out, or a move, or brand new... All Good. We provide a
>> temporary home in the Incubator to see if it can become a good, proper, and
>> healthy Apache community. We don't turn them away a-priori based on their
>> history.
>
> Greg, this seems to be so much B.S as it apparently serves some particular interest you have. A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the "owner's" blessing, regardless of what the license allowed us to do. To me, this answer is black and white.
>>
>> In my mind, the Trac core has slowed, and it needs revitalization and a new
>> vision. Others may disagree, and do, and that's fine. But I don't think it
>> is fine for us to make judgements of communities (or nascent ones!) who
>> want to try something new. To pick up and go in a direction that others are
>> not heading, or do not have the time to make.
>
> I have no idea what you are saying. You ARE making a judgement on a community by saying it isn't active enough and deserves to be forked. Again, some of your fellow board members have said the ASF isn't the place for that.
>
> Ralph
>
Re: [VOTE] Bloodhound to join the Incubator
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Jan 3, 2012 at 4:18 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Tue, Jan 3, 2012 at 9:27 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>> On Jan 3, 2012, at 12:02 AM, Greg Stein wrote:
>>> ...I'm saying that the *ASF* should avoid judging. We allow competition among
>>> projects. We accept projects with hard problems and low chances of success.
>>> We accept projects that some don't want us to. We should not judge. We
>>> should provide a home to communities that want to be here.
>>
>> I have no problem with competition among projects and everything else you say in the paragraph above. The only issue I have is that we can't take some other project's code and use it as the basis for a project here if the original project objects. It still isn't clear to me what the consensus is at Trac, but it certainly isn't overwhelmingly in favor...
>
> I agree that we don't want to support an unfriendly fork of Trac in
> Bloodhound, but as you say there doesn't seem to be an official
> consensus from the Trac project about this.
It might help to note that the policy is that ASF requires that
contributions be voluntary on the part of the people granting the
license to the ASF. That's not necessarily the same thing as 'makes
the current community happy' and it's not necessarily different --
depending on the IP status.
it looks to me as if the relevant item is "Copyright (C) 2003-2010
Edgewall Software ". So, if 'Edgewall Software" is voluntarily making
a grant, then the letter of the policy is satisfied -- even if there
are individuals in the development community who are less than
thrilled. If, on the other hand, the proposal is to just take the code
on the basis of its public license, with no expression of volition
from the owner, then I'd agree with others who see this as contrary to
the stated policy.
Nonetheless, I'm curious as to hear from Roy and Sam. Roy was
certainly the clearest articulator of this policy the last time I
recall it coming around.
>
> IMO the best way of coming to closure on this issue is for the Trac
> community (as a whole) to state whether they agree with Bloodhound
> forking whatever they are planning to fork or not. Getting that
> agreement would, again IMO, be a condition for Bloodhound to graduate.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jan 3, 2012 at 9:27 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> On Jan 3, 2012, at 12:02 AM, Greg Stein wrote:
>> ...I'm saying that the *ASF* should avoid judging. We allow competition among
>> projects. We accept projects with hard problems and low chances of success.
>> We accept projects that some don't want us to. We should not judge. We
>> should provide a home to communities that want to be here.
>
> I have no problem with competition among projects and everything else you say in the paragraph above. The only issue I have is that we can't take some other project's code and use it as the basis for a project here if the original project objects. It still isn't clear to me what the consensus is at Trac, but it certainly isn't overwhelmingly in favor...
I agree that we don't want to support an unfriendly fork of Trac in
Bloodhound, but as you say there doesn't seem to be an official
consensus from the Trac project about this.
IMO the best way of coming to closure on this issue is for the Trac
community (as a whole) to state whether they agree with Bloodhound
forking whatever they are planning to fork or not. Getting that
agreement would, again IMO, be a condition for Bloodhound to graduate.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jan 3, 2012, at 12:02 AM, Greg Stein wrote:
>
> As a person wanting to see Apache Bloodhound take off... yeah, I'm making a
> judgement call on whether that can better occur at the ASF instead of
> within the current Trac community. (fwiw, some of the ideas are
> non-starters for Trac, so the *only* solution is do it outside the core
> project).
>
> I'm saying that the *ASF* should avoid judging. We allow competition among
> projects. We accept projects with hard problems and low chances of success.
> We accept projects that some don't want us to. We should not judge. We
> should provide a home to communities that want to be here.
I have no problem with competition among projects and everything else you say in the paragraph above. The only issue I have is that we can't take some other project's code and use it as the basis for a project here if the original project objects. It still isn't clear to me what the consensus is at Trac, but it certainly isn't overwhelmingly in favor. My suggestion is to simply continue working with them to either allay any fears they may have and possibly find a way to easily share the core code. If that doesn't work then I think perhaps you need to have a discussion at the next board meeting about how to resolve it.
If it ends up that the actual Trac developers are OK with this or simply don't care then that would seem to me to be equivalent to them giving their approval. I haven't checked who has commented against the list of developers.
In the end, I would also like to see Bloodhound move forward. However, I believe we need to be careful what precedents we are setting when these kinds of issues arise. You seem to be of the opinion that getting any project that wants to come to the ASF going is what is of importance. Mine is that we need to do that while respecting the rest of the open source community.
Ralph
Re: [VOTE] Bloodhound to join the Incubator
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/3/2012 10:55 AM, Bertrand Delacretaz wrote:
> On Tue, Jan 3, 2012 at 5:48 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>> ... Folks, can we please find a better forum for religious "This is the ASF" debates
>> to occur? And keep discussions non-toxic here on general@incubator?...
>
> I don't perceive this thread as religious or toxic - I see a rather
> healthy debate on a difficult and important (for Bloodhound and Trac)
> question.
That much... is good ++1! Is Trac a willing donor/partner/component-to-be-
consumed? What is the effect of two dev communities? All healthy good
questions to raise. As easily as it creates rifts, it can also heal some.
The ASF will support a fork absolutely yes/maybe/never - that is where
I'd perceived the whole thread sliding off the rails.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jan 3, 2012 at 5:48 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>... Folks, can we please find a better forum for religious "This is the ASF" debates
> to occur? And keep discussions non-toxic here on general@incubator?...
I don't perceive this thread as religious or toxic - I see a rather
healthy debate on a difficult and important (for Bloodhound and Trac)
question.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/3/2012 2:02 AM, Greg Stein wrote:
> On Jan 3, 2012 2:30 AM, "Ralph Goers" <ra...@dslextreme.com> wrote:
>>
>> On Jan 2, 2012, at 11:15 PM, Greg Stein wrote:
>>
>>> On Jan 2, 2012 10:51 PM, "Ralph Goers" <ra...@dslextreme.com>
> wrote:
>>>>
>>>> Greg, I do not care one bit how much commit activity happens at Trac. As
>>>> long as there is some kind of active community it is improper to fork it
>>>> without their permission.
>>>
>>> Eh? You ever read the "rules for revolutionaries" page? The basic concept
>>> is: don't try to force two communities into one; when separate visions for
>>> the project occur, then separate them.
>>>
>>> I don't see it as our place to *judge* communities. If it is a fork, or a
>>> corporate spin-out, or a move, or brand new... All Good. We provide a
>>> temporary home in the Incubator to see if it can become a good, proper, and
>>> healthy Apache community. We don't turn them away a-priori based on their
>>> history.
>>
>> Greg, this seems to be so much B.S as it apparently serves some
>> particular interest you have.
>
> I *do* have an interest in seeing Bloodhound be successful. I've always
> been very impressed with the approach the Trac people have taken. It is a
> great tool. It is a great project, but I think it can be better.
>
> Bugzilla is popuar, but crap. There is no other OSS issue tracker that is
> good and popular. Trac is te closest, and (IMO) best hope for filling this
> gap in the OSS toolset.
>
>> A PMC I am on had this exact conversation with board members several
>> months ago regarding a code base the project is dependent on that is housed
>> outside the ASF which we were considering bringing in as a subproject. We
>> were told that under no circumstances could we fork the code without the
>> "owner's" blessing, regardless of what the license allowed us to do. To me,
>> this answer is black and white.
>
> Not to me. :-)
Which is the problem, isn't it? Note; hat switch, you are now speaking
with the authority of a Director.
>>> In my mind, the Trac core has slowed, and it needs revitalization and a new
>>> vision. Others may disagree, and do, and that's fine. But I don't think it
>>> is fine for us to make judgements of communities (or nascent ones!) who
>>> want to try something new. To pick up and go in a direction that others are
>>> not heading, or do not have the time to make.
>>
>> I have no idea what you are saying. You ARE making a judgement on a
>> community by saying it isn't active enough and deserves to be forked.
>> Again, some of your fellow board members have said the ASF isn't the place
>> for that.
>
> As a person wanting to see Apache Bloodhound take off... yeah, I'm making a
> judgement call on whether that can better occur at the ASF instead of
> within the current Trac community. (fwiw, some of the ideas are
> non-starters for Trac, so the *only* solution is do it outside the core
> project).
>
> I'm saying that the *ASF* should avoid judging. We allow competition among
> projects. We accept projects with hard problems and low chances of success.
> We accept projects that some don't want us to. We should not judge. We
> should provide a home to communities that want to be here.
You realize, the paragraphs above are riddled with judgement calls?
Mr. Director, are causing undue confusion here by putting on your Director
hat to contradict the board. That isn't healthy public forum conduct.
Either Ralph is grossly misinformed, or your are wildly out on a limb, or
(most likely) the whole subject matter is a whole lot more nuanced than either
of your posts are willing to concede.
I'd challenge this "we should not judge" assertion. The incubator is charged
by the directors with "the acceptance and oversight of new products submitted
or proposed to become part of the Foundation" ... go back to 6. D. R2.
http://www.apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
That involves a judgement. When you get your fellow directors to accept an
amendment to state "the acceptance and oversight of new products contributed
to the Foundation" as the responsibility - then I can buy your reasoning that
we don't cast judgements (on any number of measures).
...
Folks, can we please find a better forum for religious "This is the ASF" debates
to occur? And keep discussions non-toxic here on general@incubator?
Please remember that we point newcomers here to general@incubator and suggest
they follow that list to get a better understanding of what the ASF is.
These threads do not help to convey any clarity, and they only serve to confuse
our prospective contributors and potential, future members. Particularly when
argued between directors. Not suggesting that public debate is bad... but if
these can occur elsewhere, and -conclusions- then posted here to general@, it
would go a long ways to help newcomers orient to the philosophy and expectations
of the ASF as a whole.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Ethan Jucovy <et...@gmail.com>.
On Mon, Jan 2, 2012 at 7:26 PM, Greg Stein <gs...@gmail.com> wrote:
> The Trac community revolves mostly
> around the plugins rather than the core. I see Bloodhound as improving
> the core facilities (new features and hauling in certain plugins),
> resulting in a better default distribution (right now, you need to add
> a dozen plugins to get a useful Trac install).
There is no technical reason why building "a better default distribution"
for Bloodhound requires an imported copy of the Trac code. A Pip
requirements file[1] plus a templated trac.ini configuration file[2] along
the lines of Paste Script templates[3] would achieve this.
On Tue, Jan 3, 2012 at 3:02 AM, Greg Stein <gs...@gmail.com> wrote:
> (fwiw, some of the ideas are
> non-starters for Trac, so the *only* solution is do it outside the core
> project).
None of the public discussion about Bloodhound's intended roadmap describes
ideas that are "non-starters for Trac." As far as I have seen, the only
specific feature that's been mentioned publicly[4] is one that is on the
Trac roadmap[5].
In any case, no specific reasons have been given why building new features
"outside the core project" must happen through a code fork. Trac is highly
pluggable and hundreds of plugins already exist[6].
In a technical sense, it is very likely that the bulk of Bloodhound could
be built as a set of new Apache-licensed plugins plus an Apache-licensed
installation script and Apache-licensed configuration template or wizard.
Some of Bloodhound's plugins might require new extension points in the
Trac core. And multi-project support might require a lot of changes to the
Trac core.
Separating out these distinct aspects of the Bloodhound roadmap (a
distribution; new features; core patches necessary for those new features)
seems useful. Assuming the licensing and copyright issues can be worked
out or worked around, core patches could be submitted upstream and
locally maintained in a Mercurial patch queue[7] or a Git fork with a very
branchy workflow[8] which is used as the underlying dependency for
Bloodhound trunk development, while the rest of the project proceeds in an
Apache Subversion repository.
These may seem like excessively technical details to get into at this stage
of the discussion, but the nature of the community relationships and
information flow between the two projects, as well as the actual parameters
of the licensing and copyright questions, are significantly impacted by the
technical choices that Bloodhound's developers make at the start.
-Ethan
[1] http://www.pip-installer.org/en/latest/requirements.html
[2] http://trac.edgewall.org/wiki/TracIni
[3] http://pythonpaste.org/script/developer.html#templates
[4] http://groups.google.com/group/trac-dev/msg/9596d8067d0a4c35
[5] http://trac.edgewall.org/wiki/TracDev/Proposals/MultipleProject
[6] http://trac-hacks.org/wiki/plugin
[7]
http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
[8] https://github.com/nvie/gitflow
Re: [VOTE] Bloodhound to join the Incubator
Posted by Greg Stein <gs...@gmail.com>.
On Jan 3, 2012 2:30 AM, "Ralph Goers" <ra...@dslextreme.com> wrote:
>
>
> On Jan 2, 2012, at 11:15 PM, Greg Stein wrote:
>
> > On Jan 2, 2012 10:51 PM, "Ralph Goers" <ra...@dslextreme.com>
wrote:
> >>
> >> Greg, I do not care one bit how much commit activity happens at Trac.
As
> > long as there is some kind of active community it is improper to fork it
> > without their permission.
> >
> > Eh? You ever read the "rules for revolutionaries" page? The basic
concept
> > is: don't try to force two communities into one; when separate visions
for
> > the project occur, then separate them.
> >
> > I don't see it as our place to *judge* communities. If it is a fork, or
a
> > corporate spin-out, or a move, or brand new... All Good. We provide a
> > temporary home in the Incubator to see if it can become a good, proper,
and
> > healthy Apache community. We don't turn them away a-priori based on
their
> > history.
>
> Greg, this seems to be so much B.S as it apparently serves some
particular interest you have.
I have no financial interest, if that is what you're implying.
I *do* have an interest in seeing Bloodhound be successful. I've always
been very impressed with the approach the Trac people have taken. It is a
great tool. It is a great project, but I think it can be better.
Bugzilla is popuar, but crap. There is no other OSS issue tracker that is
good and popular. Trac is te closest, and (IMO) best hope for filling this
gap in the OSS toolset.
> A PMC I am on had this exact conversation with board members several
months ago regarding a code base the project is dependent on that is housed
outside the ASF which we were considering bringing in as a subproject. We
were told that under no circumstances could we fork the code without the
"owner's" blessing, regardless of what the license allowed us to do. To me,
this answer is black and white.
Not to me. :-)
> >
> > In my mind, the Trac core has slowed, and it needs revitalization and a
new
> > vision. Others may disagree, and do, and that's fine. But I don't think
it
> > is fine for us to make judgements of communities (or nascent ones!) who
> > want to try something new. To pick up and go in a direction that others
are
> > not heading, or do not have the time to make.
>
> I have no idea what you are saying. You ARE making a judgement on a
community by saying it isn't active enough and deserves to be forked.
Again, some of your fellow board members have said the ASF isn't the place
for that.
As a person wanting to see Apache Bloodhound take off... yeah, I'm making a
judgement call on whether that can better occur at the ASF instead of
within the current Trac community. (fwiw, some of the ideas are
non-starters for Trac, so the *only* solution is do it outside the core
project).
I'm saying that the *ASF* should avoid judging. We allow competition among
projects. We accept projects with hard problems and low chances of success.
We accept projects that some don't want us to. We should not judge. We
should provide a home to communities that want to be here.
Cheers,
-g
Re: [VOTE] Bloodhound to join the Incubator
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jan 2, 2012, at 11:15 PM, Greg Stein wrote:
> On Jan 2, 2012 10:51 PM, "Ralph Goers" <ra...@dslextreme.com> wrote:
>>
>> Greg, I do not care one bit how much commit activity happens at Trac. As
> long as there is some kind of active community it is improper to fork it
> without their permission.
>
> Eh? You ever read the "rules for revolutionaries" page? The basic concept
> is: don't try to force two communities into one; when separate visions for
> the project occur, then separate them.
>
> I don't see it as our place to *judge* communities. If it is a fork, or a
> corporate spin-out, or a move, or brand new... All Good. We provide a
> temporary home in the Incubator to see if it can become a good, proper, and
> healthy Apache community. We don't turn them away a-priori based on their
> history.
Greg, this seems to be so much B.S as it apparently serves some particular interest you have. A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the "owner's" blessing, regardless of what the license allowed us to do. To me, this answer is black and white.
>
> In my mind, the Trac core has slowed, and it needs revitalization and a new
> vision. Others may disagree, and do, and that's fine. But I don't think it
> is fine for us to make judgements of communities (or nascent ones!) who
> want to try something new. To pick up and go in a direction that others are
> not heading, or do not have the time to make.
I have no idea what you are saying. You ARE making a judgement on a community by saying it isn't active enough and deserves to be forked. Again, some of your fellow board members have said the ASF isn't the place for that.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Greg Stein <gs...@gmail.com>.
On Jan 2, 2012 10:51 PM, "Ralph Goers" <ra...@dslextreme.com> wrote:
>
> Greg, I do not care one bit how much commit activity happens at Trac. As
long as there is some kind of active community it is improper to fork it
without their permission.
Eh? You ever read the "rules for revolutionaries" page? The basic concept
is: don't try to force two communities into one; when separate visions for
the project occur, then separate them.
I don't see it as our place to *judge* communities. If it is a fork, or a
corporate spin-out, or a move, or brand new... All Good. We provide a
temporary home in the Incubator to see if it can become a good, proper, and
healthy Apache community. We don't turn them away a-priori based on their
history.
In my mind, the Trac core has slowed, and it needs revitalization and a new
vision. Others may disagree, and do, and that's fine. But I don't think it
is fine for us to make judgements of communities (or nascent ones!) who
want to try something new. To pick up and go in a direction that others are
not heading, or do not have the time to make.
>...
> Most of the concern seems to be that they would like to be able to
incorporate whatever work is done in Bloodhound back into Trac but under a
BSD license. I'm not sure why they have concerns about incorporating Apache
licensed code but simply working something out could be helpful. I suspect
hosting this project in git would also help.
I responded on trac-dev about the licensing to help answer those
questions/concerns. Git won't help since it isn't magic sauce for
licensing; it's just a tool.
Cheers,
-g
Re: [VOTE] Bloodhound to join the Incubator
Posted by Ralph Goers <ra...@dslextreme.com>.
Greg, I do not care one bit how much commit activity happens at Trac. As long as there is some kind of active community it is improper to fork it without their permission. As one of the responses on their email thread says, "Its just rude". You can choose to frame it however you want, but if the plan is to take the current Trace code base and check it in to our subversion repository, then in my book it is a fork.
That said, it is still unclear to me how this will resolve itself. I have yet to see any outright support of a fork. Mostly, "hell, no" or "it's BSD licensed, let them do what they want", which isn't exactly a resounding endorsement.
Most of the concern seems to be that they would like to be able to incorporate whatever work is done in Bloodhound back into Trac but under a BSD license. I'm not sure why they have concerns about incorporating Apache licensed code but simply working something out could be helpful. I suspect hosting this project in git would also help.
Ralph
On Jan 2, 2012, at 4:26 PM, Greg Stein wrote:
> On Sun, Jan 1, 2012 at 06:34, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Sun, Jan 1, 2012 at 12:35 AM, Hyrum K Wright
>> <hy...@wandisco.com> wrote:
>>> The Incubator proposal was publicized and discussed on trac-dev
>>> *simultaneously* with the discussion on general@incubator, and the
>>> reception was generally indifferent (as Greg mentioned earlier)
>>
>> To add some pointers to this, the trac-dev discussion thread is at
>> [1]. A related vote was just called at [2].
>>
>> The question about the fork status was also brought up [3] on general@
>> during discussion, and was IMHO answered pretty well [4].
>>
>> Obviously the fear of this being "seen as a hostile fork" did become
>> reality at least for some, so I guess there's a lesson here for us
>> all.
>
> Note that the Trac principals suggested the fork with a "let's see
> where it goes" view. It is just a few of the other committers that are
> taking issue with Bloodhound. This can be seen simply by reading the
> thread on trac-dev.
>
> I think it important to highlight that trac-dev was notified on Dec 2
> of the Bloodhound proposal, but Ethan and others didn't even notice
> for three weeks. The activity level on trunk, and the active
> committers can be seen on Ohloh:
> http://www.ohloh.net/p/trac/contributors?sort=latest_commit
>
> Looking at the timeline on trac.edgewall.org, it seems many of the
> commits are release-related or possibly on dev branches. It is kind of
> hard to tell. Trunk is certainly minimal activity.
>
> Christian is the most active committer
> (http://www.ohloh.net/p/trac/contributors/13108240188505) and has been
> supportive of the Bloodhound effort.
>
> When I looked at this, a number of months ago, I never felt that we
> were "forking" an active project. The Trac community revolves mostly
> around the plugins rather than the core. I see Bloodhound as improving
> the core facilities (new features and hauling in certain plugins),
> resulting in a better default distribution (right now, you need to add
> a dozen plugins to get a useful Trac install). This kind of work has
> not been happening on the (core) Trac project.
>
> Cheers,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Greg Stein <gs...@gmail.com>.
On Sun, Jan 1, 2012 at 06:34, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Sun, Jan 1, 2012 at 12:35 AM, Hyrum K Wright
> <hy...@wandisco.com> wrote:
>> The Incubator proposal was publicized and discussed on trac-dev
>> *simultaneously* with the discussion on general@incubator, and the
>> reception was generally indifferent (as Greg mentioned earlier)
>
> To add some pointers to this, the trac-dev discussion thread is at
> [1]. A related vote was just called at [2].
>
> The question about the fork status was also brought up [3] on general@
> during discussion, and was IMHO answered pretty well [4].
>
> Obviously the fear of this being "seen as a hostile fork" did become
> reality at least for some, so I guess there's a lesson here for us
> all.
Note that the Trac principals suggested the fork with a "let's see
where it goes" view. It is just a few of the other committers that are
taking issue with Bloodhound. This can be seen simply by reading the
thread on trac-dev.
I think it important to highlight that trac-dev was notified on Dec 2
of the Bloodhound proposal, but Ethan and others didn't even notice
for three weeks. The activity level on trunk, and the active
committers can be seen on Ohloh:
http://www.ohloh.net/p/trac/contributors?sort=latest_commit
Looking at the timeline on trac.edgewall.org, it seems many of the
commits are release-related or possibly on dev branches. It is kind of
hard to tell. Trunk is certainly minimal activity.
Christian is the most active committer
(http://www.ohloh.net/p/trac/contributors/13108240188505) and has been
supportive of the Bloodhound effort.
When I looked at this, a number of months ago, I never felt that we
were "forking" an active project. The Trac community revolves mostly
around the plugins rather than the core. I see Bloodhound as improving
the core facilities (new features and hauling in certain plugins),
resulting in a better default distribution (right now, you need to add
a dozen plugins to get a useful Trac install). This kind of work has
not been happening on the (core) Trac project.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, Jan 1, 2012 at 12:35 AM, Hyrum K Wright
<hy...@wandisco.com> wrote:
> The Incubator proposal was publicized and discussed on trac-dev
> *simultaneously* with the discussion on general@incubator, and the
> reception was generally indifferent (as Greg mentioned earlier)
To add some pointers to this, the trac-dev discussion thread is at
[1]. A related vote was just called at [2].
The question about the fork status was also brought up [3] on general@
during discussion, and was IMHO answered pretty well [4].
Obviously the fear of this being "seen as a hostile fork" did become
reality at least for some, so I guess there's a lesson here for us
all.
[1] https://groups.google.com/d/topic/trac-dev/FCaDVcbh1JQ/discussion
[2] https://groups.google.com/d/topic/trac-dev/kMVFq9pkfus/discussion
[3] http://markmail.org/message/w5efz3m2ihs7gmbw
[4] http://markmail.org/message/3ylvwqjmqqvvh3sf
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org