incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Fri, 03 Aug 2012 04:27:02 GMT
my comments below . Please recall that I'm not an expert neither in
the art of licensing nor in ASF best practices and standards .

On 8/2/12, 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:
> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
> dir is proper. (and maybe generally simplify; eg. why CHANGES in
> bloodhound_dashboard?)

Even if Bloodhound is distributed in a single file (tarball) it is
developed in the form of a set of plugins . bloodhound_* folders
contain source code for each one of them . License files are in there
because it makes sense to checkout only that particular subset of the
code in svn repos , build the corresponding plugin, install it and use
it . Indeed it's also possible to build packages for each plugin and
distribute them .

Is this a reason good enough to keep license files in bloodhound_* folders ?

> * found another NOTICE in doc/html-templates/ (?!)

+1 for removing it .

> * is doc/wireframes supposed to be shipped in the release?

I don't think so

> * would also be nice to indicate what release/revision of Trac is
> incorporated into this release,

for Release 2 (... or maybe later) we have to work on this direction.
We need to know that information in code as well . Right now it turns
out that the revision number in the footer represents changeset ID
corresponding to ASF repos rather than Trac's . My initial suggestion
is to update footer with something like

          Powered by <a
href="">Apache<sup>TM</sup></a> <a
          Standing on the shoulders of
          <a href="">Trac ${correct_trac_version}</a>
          (<a href="">modified</a>)

... notice that we can use another URL instead of

My second suggestion is to include in trunk a file named TRAC_VERSION
containing the version, changeset ID, ... of Trac code committed in
vendor branch . NOTICE , LICENSE and other files will only need to
mention that file (<= I'm hoping we can do that). File format is TBD
.. and TBH I really don't care much about it as long as it will be
readable for users interested to know after reading NOTICE , ... At
the same time it also has to be easy to parse in order to use that
value to provide correct Trac version in about page , footer , ...
i.e. everywhere Trac version will be displayed .

> along with a notice that local patches
> have been applied.

+1 ... and if current modifications need to be mentioned then maybe a
link to (or a copy of) aforementioned (non-existent) wiki page (i.e. may be included as

> (on that note: has anybody worked to push the local
> changes upstream?)

this is homework for trac-dev ML , I guess .
Nonetheless I wanted to know something in advance . If trac-dev
decides not to incorporate Bloodhound patches :

  1. may we keep them in trunk ?
  2. should we refresh and apply every time Trac source
      code is updated in vendor branch ?
  3. is there an easy (recommended ?) procedure to
      do (2) using subversion ?

PS: refresh and apply means the equivalent of executing the following
steps with Hg MQ

- hg pull <trac_repository> <vendor_branch>
- hg update tip
- hg qpush
- <modify source code by paying attention to rejected hunks>
- hg qrefresh
- hg cp <vendor branch with patches> <trunk/trac>
- hg qpop

... well something like that . I hope you get the idea ;)



Blog ES:
Blog EN:

Featured article:

View raw message