bloodhound-dev mailing list archives

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

(Note: I've been travelling recently without much internet access, and will
continue to be for the next few weeks.)

I haven't seen any significant movement on the Trac<->Bloodhound community
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 facto

Specifically, Bloodhound already depends on a patched copy of Trac which
lives in the Bloodhound SVN repository under and is
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 the
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 keeping
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 not
sure whether cutting a release that depends on a Trac distribution
maintained by Bloodhound developers in the Apache Incubator's SVN satisfies
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, instead
of distributing the patched Trac code with the release itself.

 * During the project's initiation the idea of maintaining short-term Trac
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 they

 * What tag/revision of Trac core is the code diverging from?  Where is
this documented?  How often do Bloodhound's developers merge in upstream
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 the
official Trac distribution.  (I'm not sure the best way to measure this.)
 Where are these patches (and their intentions, and the Bloodhound code
that relies on each patch) being tracked and documented as core patches?
 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 couldn't
find any such tickets.)  What procedures are in place to ensure that each
core patch is filed upstream, and to track the upstream status of each core

 * If the Trac core developers reject a patch or suggest an alternate
approach, will Bloodhound's developers take that advice and rework their
own code?  What procedures are being developed to ensure that this will
happen, rather than the expedient route of continuing to rely on a patched
Trac copy?

 * It looks like Bloodhound currently depends on three upstream Trac
plugins -- where are Bloodhound's issues filed against those plugins being

I'm aware of only one instance where an upstream patch was discussed with
the Trac community so far[5].  In that instance, a Trac developer said the
relevant plugin code was in error and suggested an alternate approach[6]
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 or
fixing it upstream, the Bloodhound release continues to use the rejected
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.  If
Bloodhound's development workflows prioritized following advice from Trac
core and submitted a good patch against ThemeEngine (maintaining a vendor
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 pretty
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 upstream
feedback.  (Though the specific "technical" questions about licensing and
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 smoothly.
 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 and
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 workflows
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 the
> 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 patches
> have been applied. (on that note: has anybody worked to push the local
> 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 vote followed by IPMC vote. (the IPMC vote will be
> easier if RAT is run first, but I can beat down any hubbub even on
> this RC1 if you go that route).
> On version numbers in general, they are cheap. There is no reason to
> have 0.1.0-RC1. Just call it 0.1 or 0.1.0. If you decide NOT to
> release it, then make the next one 0.2 or 0.1.1. Never re-use a
> number! ... but there isn't a reason to be so conservative as to make
> a 0.1.0-RC1 tarball. In the long run, you probably want a standard
> triple, so going with 0.1.0 makes sense. If people nuke that proposed
> tarball, then spin up a new one called 0.1.1. As I've mentioned
> before, once 0.1.x is out there, you probably wouldn't patch it at
> this point of BH's lifecycle, and just go straight to 0.2.0 instead.
> (tho I guess if it is a total brown-bag release, you could also do a
> teeny patch and push out 0.1.x+1).
> Anyways. Food for thought. Again, I'm +1 on this tarball for release.
> Cheers,
> -g

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