bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Trac-dev] Bloodhound / Trac Approach
Date Mon, 09 Jan 2012 17:38:13 GMT
On Sat, Jan 7, 2012 at 7:30 PM, Gary <> wrote:
> On 06/01/12 22:11, Hyrum K Wright wrote:
>> I'll let folks with more technical knowledge than myself chime in
>> here, but I'm interested to see what progresses.
>> -Hyrum
> Well, I had best get some of my ideas noted down then :)

... and I'll follow

> Just to be clear, I would like to ensure that changes to core Bloodhound are
> minimised so as to keep close compatibility with Trac. Clearly there is an
> advantage to the plugin developer community if they can expect their plugins
> to work on both systems with little or no changes. It will also mean that
> any improvements made to plugins for use in Bloodhound should automatically
> benefit Trac.

and improvements made to plugins for use in Trac should automatically
benefit Bloodhound ... ;)
that's a nice strategic decision afaics .

> Apache Bloodhound as a whole would therefore be the sum of the Bloodhound
> branch/fork of the Trac code (and so I expect this part to be under a BSD
> license),

+1 ... time will tell what goes where , btw .

> one or more Apache licensed Bloodhound plugins and possibly other
> pre-existing plugins from track-hacks.

the first one of those plugins will be support for multiple projects
in a single environment . I've put pieces together and it seems to be
possible to build it on top of 0.12-stable without hacking core "too
much " <= TBD ;)

> On 06/01/12 16:32, Olemis Lang wrote:
>> a decision needs to be made about this .
>> IMO start this from 0.12-stable is convenient so as to ensure
>> something will be ready in the next few months .
>> ;)
> Although we do want to be coming up with something soon, I think it makes
> sense to be looking at 0.13. There are two good reasons to do this: if Trac
> are going to take our code then I would expect them to want it to be
> developed against trunk; we probably want all the improvements that have
> gone into the latest code, including the latest changes to the Trac API.

I agree . I mentioned 0.12 due to the fact that during development
0.12 will be stable and everything may be developed on top of it .
>From a product perspective this will "ensure" something stable will be
ready in a "relatively" short time , and the ground will not move
underneath ;) . Once 0.12 solution will be ready then it may be
updated to work with 0.13 (quite probably this will be necessary ...
afaics some parts will need some update ;)

So, if Bloodhound as a whole is implemented so as to be distributed as
a Trac plugin ; it will be easier for users to migrate Trac
installations to Bloodhound (just like using any other plugin ;) ; and
still it may be distributed as an standalone application package .

If 0.13 is to be considered then development will need (at the same
time) to focus on developing the functional features + updating
against trunk . Most of the time what I use to do in these situations
(CMIIW) is to choose a somehow stable changeset and build features on
top of it , once finished then catch the rabbit and update to trunk .

Nonetheless both approaches are ok , afaics .

BTW , when will 0.13 be released ? I should check trac-dev schedule ;)

Before I forget , I mention now something else for us to discuss :

- What should happen with Bloodhound version numbers ?
- Should they match Trac's ?
- How will we handle tickets (may be some duplicates @ trac-dev) ?
  Maybe it would nice to have a BH plugin to forward tickets to trac-dev ,
  trac-hacks (for plugins) ...

> Obviously there are some implications for plugins there


> - I have already
> noted that some existing trac-hacks do not install properly without code
> changes.

the same happens for 0.12 . Many plugins are built for 0.11 and some
of them have not been updated for 0.12 . Sometimes they are not broken
as 0.12 did not change 0.11 in a totally backwards incompatible manner

> With luck plugin authors will either be interested in updating
> their work for the latest Trac or perhaps they might welcome a patch from
> us.


> On 06/01/12 16:32, Olemis Lang also wrote:
>> My last $0.02 is that everything I mentioned before works with a
>> central Subversion repository . We have been doing this in
>> TracXmlRpcPlugin having :
>> - central official svn repos @ trac-hacks
>> - hg mirror @ Bitbucket
>> - patch queue @ Bitbucket as well
>> in this case workflow (simplified) is as follows :
>> 1- hg mirror is updated (using hgsvn afaicr ...)
>> 2- pending patches are updated to work with tip (optional)
>> 3- new patches are created / stacked one of top of another /
>>    merged , ...
>> 4- if patch is updated , reviewed and ok then it's applied
>>    and committed into central svn repos ...
>> 5- go to step 1 ... ;)
> Yes, I think that we probably want to have an official Bloodhound repository
> for this work and it would be good to be using Bloodhound as our issue
> tracker.

Just a comment : I was thinking of using both Trac + BH running on top
of the same environment so as to ensure both web apps coexist
peacefully. This should be possible mainly if Bloodhound is available
as yet another plugin running on top of Trac, and DB schema remains
compatible with Trac's , ... but that's just a comment and kind of
academic experiment instead of a suggestion for the project itself

> Do we want this to be an svn repository?


> Have we got enough voices
> in favour of the hg patch queue to attempt that on bitbucket or has anyone

jftr , considering the fact that Bitbucket is not required so as to
use MQ there's always a chance to create the Hg repository (if any) in
project's servers, and manage everything directly . However Bitbucket
makes everything simple, provides support, simplifies CI setup
(triggers) , socializes the coding experience , and ... things like

Another important subject to discuss should be CI setup . My proposal
initially is to have

- Bitbucket mirror of Trac repos
- Bitbucket patch queues (to work on tickets)
- Bitbucket central patch queue archive (incorporating changes to
accepted patches)
- Jenkins CI @ . In there I created once upon a time a
build job for
  Trac XmlRpcPlugin so as to run tests on its Bitbucket patch queue .
- ...




Facebook =>
Twitter => (@olemislc)
Blog ES =>
Blog EN =>
Quora =>
Youtube =>

Featured article : El SPDY de Google no es tan malo como el Internet
Explorer (IMO)
Tweet: El SPDY de #Google no es tan malo como el Internet Explorer
(IMO) #Simelo #blog #fb #windows
Follow @olemislc Reply Retweet   13:22 Jan-05
  Get this email app!
Get a signature like this. CLICK HERE.

View raw message