incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jucovy <>
Subject Re: [VOTE] Bloodhound to join the Incubator
Date Tue, 03 Jan 2012 13:21:00 GMT
On Mon, Jan 2, 2012 at 7:26 PM, Greg Stein <> 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 <> 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.



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