incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [VOTE] Bloodhound to join the Incubator
Date Tue, 03 Jan 2012 08:27:40 GMT

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message