-1 (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 fork. 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. * 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 would? * 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? * 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 trac.edgewall.org 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 patch? * 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 tracked? 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. -Ethan [1] http://www.mail-archive.com/[email protected]/msg00003.html [2] http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201201.mbox/%[email protected]%3E [3] http://osdir.com/ml/trac-dev/2012-01/msg00023.html [4] http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%[email protected]%3E [5] http://old.nabble.com/Create-new-ticket-vs-reopen--9418-(if-necessary--)-td33164546.html [6] http://old.nabble.com/Re%3A-Create-new-ticket-vs-reopen--9418-%28if-necessary--%29-p33176708.html [7] https://issues.apache.org/bloodhound/ticket/27 [8] http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/201204.mbox/%3CCAGMZAuPywg_QLUfiL4MEAR-57at22V8Oe=yhr1+hy3m8sxo...@mail.gmail.com%3E [9] http://trac-hacks.org/ticket/9580#comment:3 On Thu, Aug 2, 2012 at 2:14 PM, Greg Stein <[email protected]> wrote: > On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <[email protected]> > 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/macros.py > - 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 >
