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 Tue, 10 Jan 2012 16:06:53 GMT
On Tue, Jan 10, 2012 at 8:13 AM, Gary <> wrote:

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

me neither , but there's still a chance to «be nice» ;)

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

exactly !
Even if I didn't mention this before it seems we are in sync (as that's a
bit straightforward reasoning ;)
In fact I was thinking of considering projects as yet another Trac resource
and therefore try to implement such mapping as similar to TracRelations
spec [1]_ as possible / needed .

> 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 :)
What'd be the pros & cons of (1 - project to resource mapping table) vs (2
- extra project field) ?
IMO #1 is in sound with the more generic TracRelations proposal (as far as
DB is concerned , project-specific behavior is another $0.02 ;) whereas #2
breaks the more generic resource relations framework @ the DB level .

... question may also be reformulated this way : Considering TracRelations
is out there , what makes projects so special so as to make an exception
with them at the DB-level ?

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.
... once I submitted project labels proposal [2]_ to trac-dev it was noted
(with strong arguments IMO) that resource history may be important to be
tracked as well . For project labels it makes sense . Maybe we should
consider whether history meta-data might be appropriate for projects & what
events exactly will be tracked during project lifetime .

maybe a few fields like creation time , owner , project logo (i.e. project
fields used in trac.ini ;) should also be considered for inclusion in there
. I like the idea of being able to consider projects just like if they were
yet another Trac environment inside an environment . That way e.g. external
environment may be merged within another and become a project located at a
given level of project hierarchy . All that metadata should be kept and
reused in new project living (<= oh ! I really wanted to say that ... life
is beautiful :) inside target environment . Another goal might be to have
all this implemented causing the least impact over existing plugins ,
preferably no side-effects .

This makes me wonder whether it would be appropriate to have :

- project_config table : basically a mirror of trac.ini inside
  database (fields TBD ;)
- trac.config classes implemented on top of database backend
- environment wrapper class so as to include in there
  project specific features (e.g. DB-aware config objects) .
  This will be necessary so as to make plugins auto-magically
  compatible with the new architectural changes . I mean as
  far as plugins (request handlers, filters , ...) are concerned
  they'll see an environment (i.e. object) looking exactly like
  environments used to look like , but with some methods
  aware of multi-project context e.g. project-specific config in DB
- Semantics of DB-specific config components should be exactly the
  same as if DB config fields were in yet another trac.ini file
  inheriting [3]_ from "real" environment trac.ini file (maybe config
  inheritance across project hierarchy is also good to have ,
  but definitely a bit more difficult to implement)
- Components in Bloodhound (e.g. like TracIniAdmin plugin) to
  customize project specific settings stored in the DB

... all this for single project requests . Request involving multiple
projects (e.g. labels [1]_ ) should not consider all this (should they ?

Maybe project_config proposal is a bit ambitious to include it in the short
term but I'd rather keep it under my pillow at least for review.
Isn't the Trac-ky thingy just lovely ?
I hope we all can make it better ...

Personally I would also like to see independent ticket numbering per
> project but this may be too ambitious.

maybe possible with #2 above but definitely not with #1 ; but even if #2
allows to do so ...

> 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.
... maybe it's not a good idea considering your comment above . If ticket
has its own identity (like it happens right now as opposite to project ID +
ticket ID) references will always be valid (just like it happens right now)
, no matter what relations it has with other resources (e.g. projects) and
how they change with time . IMO going for #2 + independent ticket numbering
may lead to over-complicating a system that just works right now . In any
case that doesn't mean that visually e.g. project ID (e.g. short_name)
might be displayed in ticket link text.

>  Although we do want to be coming up with something soon, I think it makes
>>> sense to be looking at 0.13.
>>> [...]

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

>  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.
If a decision is made to adopt #1 approach (i.e. project to resource
mapping table) mentioned above and keep schema of Trac tables just like it
is nowadays then it would possible to have both a Trac instance and a
Bloodhound instance (with e.g. multi-project support ;) running on top of
the same environment . Ok, some decisions may jeopardize success , but that
only means that Bloodhound is not compatible with Trac at some point .

.. [1] Trac Relations
.. [2] Project classifiers (aka labels)
.. [3] Global configuration



Facebook =>
Twitter => (@olemislc)
Blog ES =>
Blog EN =>
Quora =>
Youtube =>
Featured article : El SPDY de Google no es tan malo como el Internet
Explorer (IMO)<>
 Get a signature like this.

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