bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Thu, 02 Aug 2012 23:22:13 GMT
Hi Ethan,

I will consider your response in greater detail in the morning.

I will check up on the file you found in the trac directories. This would indeed be a mistake.

In a very general point on the rest of your concerns, there remains no intention to fork as
it would not be in the best interest of any of the communities involved, and we will be discussing
the changes that we find to be requirements of our solution with trac in the hope that these
would enhance trac as well.

Anyway, I will talk more about this in the morning. Thanks for the input.


Ethan Jucovy <> wrote:

>(Note: I've been travelling recently without much internet access, and
>continue to be for the next few weeks.)
>I haven't seen any significant movement on the Trac<->Bloodhound
>issues discussed during Bloodhound's initial project proposal.  The
>Bloodhound developers also seem to have backtracked on the specific
>resolutions made during the initial discussions, and haven't yet
>established any workflows or documentation to ensure good communication
>with the Trac community.  If these issues are not addressed before the
>initial release, Bloodhound's current working code and development
>workflows will gain inertia, and increase the risk of a permanent de
>Specifically, Bloodhound already depends on a patched copy of Trac
>lives in the Bloodhound SVN repository under
> and
>distributed with the release.  This raises a number of questions:
> * Some of the files in Bloodhound's modified copy of Trac core contain
>"Licensed to the Apache Software Foundation" headers.
>(trac/utils/tests/ and trac/util/ are
>ones I've noticed, but I didn't grep the repository.)  I think this is
>contrary to previous claims that Bloodhound's developers would keep all
>Trac modifications BSD-licensed, and that the individual authors would
>retain their copyright over these lines of code, for the sake of
>Trac's BSD license intact for all upstream patches[1].  These license
>headers should be removed before a release.
>* Based on the earlier discussions on the Apache Incubator list, I'm
>sure whether cutting a release that depends on a Trac distribution
>maintained by Bloodhound developers in the Apache Incubator's SVN
>ASF's guidelines and policies.  The patched Trac distribution should
>probably be moved to a public code-hosting site like Sourceforge,
>Github or
>Bitbucket, instead of continuing to live in the ASF SVN.  The release
>should then point to a tag at that new location for installation,
>of distributing the patched Trac code with the release itself.
>* During the project's initiation the idea of maintaining short-term
>patches in a branch-heavy Git repository or Mercurial patch queue was
>discussed[2, 3, 4] to facilitate a good upstream contribution workflow.
>Why did Bloodhound's developers not take this approach after saying
> * What tag/revision of Trac core is the code diverging from?  Where is
>this documented?  How often do Bloodhound's developers merge in
>changes, and what is their policy for deciding when to merge upstream
>* The patched copy of Trac seems to have a few-hundred-line diff from
>official Trac distribution.  (I'm not sure the best way to measure
> Where are these patches (and their intentions, and the Bloodhound code
>that relies on each patch) being tracked and documented as core
> What procedures are in place to ensure that each core patch is being
>tracked and documented?
> * Have all of these patches been submitted upstream to the Trac core
>community?  Where are the upstream submissions being tracked and
>documented?  (I tried several searches on and
>find any such tickets.)  What procedures are in place to ensure that
>core patch is filed upstream, and to track the upstream status of each
> * If the Trac core developers reject a patch or suggest an alternate
>approach, will Bloodhound's developers take that advice and rework
>own code?  What procedures are being developed to ensure that this will
>happen, rather than the expedient route of continuing to rely on a
>Trac copy?
> * It looks like Bloodhound currently depends on three upstream Trac
>plugins -- where are Bloodhound's issues filed against those plugins
>I'm aware of only one instance where an upstream patch was discussed
>the Trac community so far[5].  In that instance, a Trac developer said
>relevant plugin code was in error and suggested an alternate
>that would patch the faulty plugin code instead of working around it
>with a
>core patch.  This was filed but has not yet been acted on[7], and
>Bloodhound's developers did not all seem to agree that the advice from
>upstream should be followed[8, 9]; instead of patching the plugin code
>fixing it upstream, the Bloodhound release continues to use the
>core Trac patch.
>The plugin in question is well known and hasn't been maintained by its
>original author for more than two years (hence its incompatibility with
>Trac trunk) so this is a good example of why these questions matter. 
>Bloodhound's development workflows prioritized following advice from
>core and submitted a good patch against ThemeEngine (maintaining a
>branch // patch queue // short-lived fork of the plugin code in the
>meantime) then one of Bloodhound's developers could probably adopt
>maintenance for the plugin through existing Trac community channels
>easily, which would benefit the wider Trac community.
>To be clear, I don't think Bloodhound's initial releas requires a
>completely smooth procedure and infrastructure for tracking patches,
>submitting upstream contributions, and reworking changes based on
>feedback.  (Though the specific "technical" questions about licensing
>code location should be addressed now.)
>But those questions should be considered part of the release process.
>Partly because it's the best/only formal opportunity in the development
>cycle to make sure the upstream/downstream workflow is running
> And also because, after a release is made, inertia will build for just
>leaving patches in place as-is instead of waiting for upstream feedback
>potentially rewriting features that are already working in the wild. 
>So I
>think it would be more prudent to postpone the initial release until
>working first drafts of these knowledge-maintenance/collaboration
>have been established among Bloodhound's developers.
>On Thu, Aug 2, 2012 at 2:14 PM, Greg Stein <> wrote:
>> On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin
>> wrote:
>> >...
>> > Please vote:
>> > [ ] +1 Release this package as Apache Bloodhound 0.1.0
>> > [ ] +0 Don't care
>> > [ ] -1 Do not release this package (please explain)
>> +1 to release.
>> Changes that I'd suggest for the next release:
>> * append dependencies' licenses to LICENSE (in addition to their
>> reference in NOTICE)
>> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
>> dir is proper. (and maybe generally simplify; eg. why CHANGES in
>> bloodhound_dashboard?)
>> * found another NOTICE in doc/html-templates/ (?!)
>> * is doc/wireframes supposed to be shipped in the release?
>> * found another LICENSE/NOTICE pair in installer/
>> * files like bloodhound_dashboard/setup.cfg (and other .ini format
>> files like ticket_data.ini) could use a license header (use of RAT
>> will find more of these)
>>   - same with bloodhound_dashboard/
>>   - run RAT before 0.2 release
>> * in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
>> then comment holding the license header comes before the DOCTYPE
>> element. not sure that is (formally) allowed. probably should have
>> DOCTYPE, then the comment, then the <div>
>> * might be nice to have a top-level README that points to
>> installer/README.rst
>> * would also be nice to indicate what release/revision of Trac is
>> incorporated into this release, along with a notice that local
>> have been applied. (on that note: has anybody worked to push the
>> changes upstream?)
>> That's all for now. While I think this it is fine to release in this
>> shape, I might also suggest incorporating the above changes and
>> produce a 0.1 tarball (no RC1 designator) and shoot that out for
>> another BH release

View raw message