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 Fri, 03 Aug 2012 10:18:28 GMT
Given Greg's response I hardly need to cover anything now so I will 
leave my additional contributions to a few, hopefully short comments.

On 08/02/2012 11:42 PM, Ethan Jucovy wrote:
> 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.

Whilst it was not my intention to leave the file mentioned with that 
license header, Greg's assertions that this is actually correct are good 
enough for me for the moment. IF changes of this sort are accepted into 
Trac then I would expect the license headers of such files in the 
Bloodhound repository to reflect what they are in the Trac repositories. 
Meanwhile, I am certainly going to consider the suggestion from Olemis 
that the file is moved elsewhere, but this will not be considered a 
change required for 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. [...]

 From what I could tell, the vendor branch solution is entirely 
acceptable and keeps a clear record of the differences directly in the 
repositories. I think it is quite a neat, clear and convenient solution 
for Bloodhound.

>   * 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
> would?

I do come back to this myself every now and then. It is not so much a 
final decision as what is necessary for us to get our work done on a 
continuing basis.

>   * 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
> changes?

How we do the job of merging changes from Trac is really more our 
problem but the general principles are specified here:

As for policy on when to merge, there is no policy and I do not wish to 
enforce one at this point. As a general principle I would like the 
vendor code to be considered for updating once a release but we should 
not need to commit to anything at this point. It would be normal to 
discuss the need for such changes on this list.

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

I also do not know how this is particularly relevant. However, at the 
moment we would probably expect to track the issue locally as well as 
notify in the plugin's issue tracker. There are already examples of this 
happening and so far interactions of this form have been largely 
positive when there is a response.


View raw message