On Mon, Jan 2, 2012 at 7:26 PM, Greg Stein <gst...@gmail.com> wrote: > The Trac community revolves mostly > around the plugins rather than the core. I see Bloodhound as improving > the core facilities (new features and hauling in certain plugins), > resulting in a better default distribution (right now, you need to add > a dozen plugins to get a useful Trac install).
There is no technical reason why building "a better default distribution" for Bloodhound requires an imported copy of the Trac code. A Pip requirements file[1] plus a templated trac.ini configuration file[2] along the lines of Paste Script templates[3] would achieve this. On Tue, Jan 3, 2012 at 3:02 AM, Greg Stein <gst...@gmail.com> wrote: > (fwiw, some of the ideas are > non-starters for Trac, so the *only* solution is do it outside the core > project). None of the public discussion about Bloodhound's intended roadmap describes ideas that are "non-starters for Trac." As far as I have seen, the only specific feature that's been mentioned publicly[4] is one that is on the Trac roadmap[5]. In any case, no specific reasons have been given why building new features "outside the core project" must happen through a code fork. Trac is highly pluggable and hundreds of plugins already exist[6]. In a technical sense, it is very likely that the bulk of Bloodhound could be built as a set of new Apache-licensed plugins plus an Apache-licensed installation script and Apache-licensed configuration template or wizard. Some of Bloodhound's plugins might require new extension points in the Trac core. And multi-project support might require a lot of changes to the Trac core. Separating out these distinct aspects of the Bloodhound roadmap (a distribution; new features; core patches necessary for those new features) seems useful. Assuming the licensing and copyright issues can be worked out or worked around, core patches could be submitted upstream and locally maintained in a Mercurial patch queue[7] or a Git fork with a very branchy workflow[8] which is used as the underlying dependency for Bloodhound trunk development, while the rest of the project proceeds in an Apache Subversion repository. These may seem like excessively technical details to get into at this stage of the discussion, but the nature of the community relationships and information flow between the two projects, as well as the actual parameters of the licensing and copyright questions, are significantly impacted by the technical choices that Bloodhound's developers make at the start. -Ethan [1] http://www.pip-installer.org/en/latest/requirements.html [2] http://trac.edgewall.org/wiki/TracIni [3] http://pythonpaste.org/script/developer.html#templates [4] http://groups.google.com/group/trac-dev/msg/9596d8067d0a4c35 [5] http://trac.edgewall.org/wiki/TracDev/Proposals/MultipleProject [6] http://trac-hacks.org/wiki/plugin [7] http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html [8] https://github.com/nvie/gitflow
