incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <j...@digiverse.si>
Subject Re: [Apache Bloodhound] #115: Product-specific settings
Date Wed, 09 Jan 2013 10:50:43 GMT
On 1/8/13 9:07 AM, Olemis Lang wrote:
> On 12/21/12, Jure Zitnik <jure@digiverse.si> wrote:
>> On 12/20/12 10:26 PM, Olemis Lang wrote:
>>> On 12/19/12, Apache Bloodhound <bloodhound-dev@incubator.apache.org>
>>> wrote:
>>>>    I'll be developing this in [https://bitbucket.org/olemis/bloodhound-mq
>>>> my
>>>>    patch queue @ Bitbucket] in [https://bitbucket.org/olemis/bloodhound-
>>>>    mq/commits/all/tip/branch(%22t115_product_env%22) branch
>>>> t115_product_env]
>>>>
>>> Today I have submitted new versions of these patches (in branch
>>> t115_product_env ) aimed at running tests for Trac environments
>>> against product environments .
>> Great, will take a look.
> it's done now , so enjoy !
> ;)

I commited patches in r1430768.

I started integrating ProductEnvironment with the database proxy (#288), 
environment factory (#322) and global hooks (#323).

A question re ProductEnvironment class - is there a specific reason for 
that class not being derived directly from trac.env.Environment? I'm 
asking this as I was planning on replacing (monkey patching) 
trac.env.Environment with our implementation of the environment. This 
way we have control over database connection in all environments (global 
and per product). Making that (our env) a base class for 
ProductEnvironment would make things more consistent.

Also, I was thinking of renaming ProductEnvironment.env to 
ProductEnvironment.parent or ProductEnvironment.global (as set forth in 
BEP-0003). What's your take on this, do you have any objections?

>> any chance of rebasing those patches
>> against the multiproduct branch (bep_0003_multiproduct)?
> of course . IMO they should work with no or little modifications ...
> especially depending on base version (common ancestor) of
> bep_0003_multiproduct with respect to trunk . Do you merge changes in
> trunk relatively often ?

Thanks for the rebase. Until yesterday the trunk merge frequency was 
rather low but is set to increase ;)


> so it is the other way round . What's the next step for multi-product
> support ? What shall I do ?

Next step for the multi-product is the integration I'm working on at the 
moment (mentioned above). Depending on how this goes we'll see where to 
head next ... there are already number of tickets re UI changes related 
to multi-product (324-329) so that'd be the most obvious way.

Cheers,
Jure



Mime
View raw message