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
duplication.
- 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.
Cheers,
Gary
