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
https://svn.apache.org/repos/asf/incubator/bloodhound/trunk/trac/ 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/introspection.py and trac/util/introspection.py 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:
http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html
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.
Cheers,
Gary
