incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: [Apache Bloodhound] #115: Product-specific settings
Date Thu, 10 Jan 2013 03:15:17 GMT
On 1/9/13, Jure Zitnik <jure@digiverse.si> wrote:
> 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 see . I'll try to explain something we've being doing since long
time ago (based on Gary's suggestions) and I think is very helpful .

Commits should be focused considering their intent . The more focused
the better . That's exactly why I developed three patches for
(related) features : 1. product environments , 2. product config , 3.
test code . Therefore each patch should be applied in a separate
changeset (e.g. like in #146 [1]_ )

You might say Ā«that's insaneĀ» ... but take as example #341 [2]_ which
is a regression after #146 . As I've also followed the same approach
to build the patches I submit , it's possible to identify the exact
point [3]_ where this very same issue was fixed once upon a time (...
so let's all hail Gary ! )

> I started integrating ProductEnvironment with the database proxy (#288),

good .

> environment factory (#322)

I'll take a look to see what's been done about this ... is there
anything already in svn repos ?

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

We've been talking about this via #bloodhound @ freenode . Could you
please post a summary ?

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

I've mentioned this before and mentioned that the way to go should be
to install product-specific DB proxies in each instance of
ProductEnvironment class . In order to do that (and in general)
there's no need to extend Environment class at all . ProductEnvs are
wrappers .

> Making that (our env) a base class for
> ProductEnvironment would make things more consistent.
>

I don't think so .

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

about attribute name ? not really ...

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

wise words

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

Well for the time being I'll follow with product-specific component
rules , which does not require DB access but configuration fu .

> there are already number of tickets re UI changes related
> to multi-product (324-329) so that'd be the most obvious way.
>

maybe later ... ;)

.. [1] Ticket #146
        (https://issues.apache.org/bloodhound/ticket/146#comment:41)

.. [2] Ticket #341
        (https://issues.apache.org/bloodhound/ticket/341#comment:4)

.. [3] BH Theme #146 : Workflow drop down visible on affix
        (https://bitbucket.org/olemis/bloodhound_theme-mq/commits/68a6509eb10c258b16cf7a287dace19c1bfcaa4b)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message