incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary <>
Subject Re: [Trac-dev] Bloodhound / Trac Approach
Date Tue, 10 Jan 2012 13:13:52 GMT
On 01/09/2012 05:38 PM, Olemis Lang wrote:
>> 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 ;)
Yes, this is an interesting area and I have been looking at it quite 
carefully. I am not yet certain of how little we can get away with 
changing the schema and behaviour. I think we certainly need a project 
table and we might be able to avoid changing existing tables by also 
providing a table that maps resources to their project. Or we could just 
add the extra project field to the appropriate tables. There is 
something appealing to me about the latter no-nonsense approach :)

Either way I was thinking of providing projects with at least the 
following details

  * name
  * short_name (unique and fixed)
  * description

where the short_name acts as a label in any referencing between projects.

Personally I would also like to see independent ticket numbering per 
project but this may be too ambitious. If we manage this, however, it 
should simplify the combining of multiple existing environments into a 
single project from the user's perspective: existing commit messages and 
internal ticket links within a project would be able to remain consistent.

>> 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 .
That would of course be possible for Bloodhound plugins that are not 
dependant on a Bloodhound core.

> 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 .
That is not unreasonable. Deciding how to distinguish stable revisions 
will be interesting of course :).

Does anyone have any reason to consider 0.13 particularly unstable? I 
assume that there is a relative lack of 0.13 user base to judge 
stability with of course.

> - 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) ...

I have no particularly strong feelings about how version numbers should 
match or otherwise.

I think that some kind of duplication of tickets is to be expected but 
any effort that goes into bloodhound should be documented on Bloodhound 
appropriately. As much as possible I would like to see our tickets 
referencing the Trac site properly with InterTrac links to reduce real 

>> - 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

There is definitely a potential problem in the 0.12->0.13 change with 
database handling when a plugin expects methods on the db object that 
have been removed but I only spotted a few cases so far (at least one of 
which may have been fixed already).

>> 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.
> +1
> 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
> ;)
That could be interesting. I was about to say that it should be possible 
but, with the changes to the database, I think we will have to deal with 
some interesting issues if I remember correctly.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message