incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [Apache Bloodhound] Proposals/BEP-0003 modified
Date Thu, 15 Nov 2012 15:33:00 GMT
Maybe I misunderstood how this BEP thing should work.
I think that the only correct way of doing this that conforms with Apache
rules would be to discuss things on ML first. BEP is a nice add-on but can
not be anything more then a summary of a ML discussion.

Could be that my interpretation of the ML role is a bit too "strict" :)

Peter

On 15 November 2012 16:15, Gary Martin <gary.martin@wandisco.com> wrote:

> Hmm.. a very good question. It still represents a proposal rather than
> something that we already agree on. It is not yet clear that the proposal
> will meet our requirements in the form that it takes.
>
> I will need to study the proposal as it evolves before I go with it but it
> is possible we can be able to pick out parts of the proposal that we can
> agree on for early implementation. I guess we'll see how it goes.
>
> Cheers,
> Gary
>
>
> On 15/11/12 12:51, Peter Koželj wrote:
>
>> I am a bit confused here. It was only yesterday that we where still
>> discussing the features that multiproduct should bring and today I am
>> looking at BEP that already has hints of agreed and rejected solutions and
>> other stuff and I am not even certain that we agreed on features yet.
>>
>> Did I miss something in ML archives?
>>
>> Peter
>>
>> On 15 November 2012 08:08, Apache Bloodhound <
>> bloodhound-dev@incubator.**apache.org<bloodhound-dev@incubator.apache.org>>
>> wrote:
>>
>>  Page "Proposals/BEP-0003" was changed by olemis
>>> Diff URL: <
>>> https://issues.apache.org/**bloodhound/wiki/Proposals/BEP-**
>>> 0003?action=diff&version=7<https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=7>
>>> Revision 7
>>> Comment: [BEP-0003] Towards an introduction to product environments (not
>>> finished)
>>> Changes:
>>> -------8<------8<------8<-----**-8<------8<------8<------8<---**
>>> ---8<--------
>>> Index: Proposals/BEP-0003
>>> ==============================**==============================**
>>> =============
>>> --- Proposals/BEP-0003 (version: 6)
>>> +++ Proposals/BEP-0003 (version: 7)
>>> @@ -24,27 +24,127 @@
>>>
>>>   == Motivation ==
>>>
>>> -Nowadays it is possible to manage multiple projects by creating multiple
>>> environments. As a consequence data is scattered across multiple
>>> databases
>>> and maintenance tasks turn out to be more difficult. Since a long time
>>> users have expressed the need for managing multiple ''projects'' in an
>>> easy
>>> way . In the case of a family of related products it is usually important
>>> to have a unified view on the development activity as well as the ability
>>> to share common resources among them. Under those circumstances it is
>>> convenient to manage multiple products within a single ''Trac''
>>> environment.
>>> +Nowadays it is possible to manage multiple projects by creating multiple
>>> environments. One notable example is [./MultienvParentDir the
>>> multi-environment setup] considered as a reference for this
>>> specification.
>>> As a consequence data is scattered across multiple databases and
>>> maintenance tasks turn out to be more difficult. Since a long time users
>>> have expressed the need for managing multiple ''projects'' in an easy
>>> way .
>>> In the case of a family of related products it is usually important to
>>> have
>>> a unified view on the development activity as well as the ability to
>>> share
>>> common resources among them. Under those circumstances it is convenient
>>> to
>>> manage multiple products within a single ''Trac'' environment.
>>>
>>>   The term ''project'' is very generic and may be confusing considering
>>> the
>>> context. Therefore in this specification the word ''product'' is used
>>> instead .
>>>
>>>   == Proposal #proposal
>>>
>>> -'''TODO'''
>>> +In a few words the current proposal tries to reproduce a well-known
>>> [./MultienvParentDir multi-environment setup] inside a single enviroment.
>>> In this section you'll find the most important details necessary to
>>> implement multi-product support. In order to understand the reasons that
>>> make this is a valid and reliable specification, please see [#rationale
>>> Rationale] below. In order and know more about similar alternatives
>>> rejected along the way, please consult [#rejected Rejected ideas] below.
>>> +
>>> +=== Product environments #product-envs
>>> +
>>> +The key design mechanism is known as ''product environments'' . Their
>>> main goal is to provide components (both in core and those defined by
>>> plugins) with a lightweight virtual representation of an isolated
>>> environment inside the ''global'' environment when dealing with requests
>>> addressed to a resource owned by a product. The following figure
>>> illustrates how they work.
>>> +
>>> +[[Image(Product_environments.**png)]]
>>> +
>>> +If you notice similarities with the
>>> [attachment:wiki:Proposals/**BEP-0003/MultienvParentDir:**
>>> Multienv_small.png
>>> reference multi-environment setup] it is an intentional design decision.
>>> +
>>> +=== Product extensions to the trac.env.Environment API #product-env-api
>>> +
>>> +There is no need to create ''product environments'' explicitly via
>>> [TracAdmin trac-admin] commands. Provided that the target product exists
>>> in
>>> the database, they will be instantiated like shown in the following code
>>> snippet. The instance of `trac.env.Environment` representing the global
>>> environment will be accessed via `parent_env` attribute. The target
>>> product
>>> will be available in `product` attribute.
>>> +
>>> +{{{
>>> +#!py
>>> +
>>> +>>> env
>>> +<trac.env.Environment object at 0x7faacb1e9490>
>>> +>>> from multiproduct.env import ProductEnvironment
>>> +>>> product_env = ProductEnvironment(env, product_prefix)
>>> +>>> product_env.parent_env
>>> +<trac.env.Environment object at 0x7faacb1e9490>
>>> +>>> product_env.product
>>> +<multiproduct.model.Product object at 0x35566d0>
>>> +
>>> +}}}
>>> +
>>> +Product environments will not be recursive , which means that the
>>> following statement will fail
>>> +
>>> +{{{
>>> +#!py
>>> +
>>> +>>> new_product_env = ProductEnvironment(product_**env, product_prefix)
>>> +Traceback (most recent call last):
>>> +  File "<stdin>", line 1, in <module>
>>> +TypeError: Initializer must be called with
>>> +    trac.env.Environment instance as first argument
>>> +    (got multiproduct.env.**ProductEnvironment instance instead)
>>> +
>>> +}}}
>>> +
>>> +Instantiating a component involved in multi-product architecture will
>>> always return `None`, just like if it was disabled e.g.
>>> +
>>> +{{{
>>> +#!py
>>> +
>>> +>>> ps = product.api.**MultiProductSystem(product_**env)
>>> +>>> repr(ps)
>>> +None
>>> +}}}
>>> +
>>> +''Product environments'' will implement both
>>> `trac.core.ComponentManager`
>>> and `trac.core.Component` APIs by inheriting most of the properties of
>>> the
>>> global `trac.env.Environment`, so they will act as wrappers. As a
>>> consequence instances will have its own components cache, which means
>>> that
>>> every active component class will only have a single instance for every
>>> product environment.
>>> +
>>> +The following list explains how product environments will adapt existing
>>> environment API while still being compatible with it.
>>> +
>>> +  - '''[=#product-env-conf] conf''' will contain an
>>> +    instance of `trac.conf.Configuration` (or equivalent) setup in
>>> +    such a way that it reads product-specific
>>> +    settings from a file located at path
>>> +    `./conf/product_<product prefix>.ini` relative
>>> +    to the global environment's directory and
>>> +    inherits globals settings stored in
>>> +    `./conf/trac.ini` file. Some exceptions needs to
>>> +    be installed in place.
>>> +    * '''TODO'''
>>> +  - '''[=#product-env-shared_**plugins_dir] shared_plugins_dir''' will
>>> always be empty . There
>>> +    will be no way to deploy plugins for a particular
>>> +    product, just enable/disable those installed in
>>> +    the global environment.
>>> +  - '''TODO'''
>>> +
>>> +[=#product-env-idem] The following methods and options will behave
>>> exactly the same as the corresponding `parent_env`'s methods:
>>> ''get_system_info'' , ''components_section'' , '''TODO''' .
>>>
>>>   == Rationale #rationale
>>>
>>>   The following is a list of proposed features for multi product support
>>> in
>>> ''Bloodhound''. Goals related to compatibility are considered in
>>> [#backwards-compatibility Backwards compatibility] below. In each case
>>> you'll find notes explaining how candidate implementation will solve
>>> related issues.
>>>
>>> +=== Per product ticket workflow #workflow
>>> +
>>> +Depending on the product, different ticket workflows should be
>>> supported.
>>> +
>>> +=== Per product notifications
>>> +
>>> +Notifications should be configurable per product.
>>> +
>>> +=== Per product ticket field configuration
>>> +
>>> +Components, milestone, version, priority, defaults, custom fields should
>>> be configurable per product.
>>> +
>>> +=== Per product permission scheme #permissions
>>> +
>>> +Permission scheme is defined by assigning permissions (from a predefined
>>> permission list) to specific users or groups. Permission scheme is
>>> assigned
>>> to a product.
>>> +
>>> +==== Product roles #roles
>>> +
>>> +Support for per product user groups. Roles can be used to configure
>>> notifications and permissions per product.
>>> +
>>>   === Product resources namespaces #url-mapping
>>>
>>> -Product and resource ID should form a two dimensional namespace. The
>>> mapping
>>> -
>>> -Each resource would in addition to current URL scheme also be
>>> addressable
>>> through the product URL namespace, namely /ticket/<product prefix>/<local
>>> ticket id>.
>>> +Product and resource ID should form a two dimensional namespace. The
>>> mapping should be flexible enough to support the following scenarios .
>>> +
>>> +  - '''Product path namespace''' : '''TODO'''
>>> +  - '''Product sub domain''' : '''TODO'''
>>> +  - '''Product sub domain + path namespace''' : '''TODO'''
>>> +
>>> +'''FIXME''' also be addressable through the product URL namespace,
>>> namely
>>> /ticket/<product prefix>/<local ticket id>.
>>> +
>>> +In a multi-product configuration product resources should not be
>>> accessed
>>> using current global URL scheme (i.e.
>>> /path/to/bloodhound/<**environment>/<realm>/<id>). '''TODO'''
why ?
>>>
>>>   ==== Tickets #tickets-namespace
>>>
>>> -Each product would have a separate number sequence for product ticket
>>> IDs.
>>> +Tickets will keep their absolute ID and will be unique in the context of
>>> the global environment. Besides each product would have a separate number
>>> sequence for product ticket IDs.
>>> +
>>> +  '''TODO:''' Implementation details TBD
>>>
>>>   === Resources moveable between products #migration-resource
>>>
>>> @@ -54,30 +154,10 @@
>>>
>>>   By default, search is global. Search and queries should allow search
>>> queries to be limited to specific product.
>>>
>>> -=== Per product ticket workflow #workflow
>>> -
>>> -Depending on the product, different ticket workflows should be
>>> supported.
>>> -
>>>   === Inter product ticket relations
>>>
>>>   It should be possible to link tickets from different products.
>>>
>>> -=== Per product notifications
>>> -
>>> -Notifications should be configurable per product.
>>> -
>>> -=== Per product ticket field configuration
>>> -
>>> -Components, milestone, version, priority, defaults, custom fields should
>>> be configurable per product.
>>> -
>>> -=== Per product permission scheme #permissions
>>> -
>>> -Permission scheme is defined by assigning permissions (from a predefined
>>> permission list) to specific users or groups. Permission scheme is
>>> assigned
>>> to a product.
>>> -
>>> -==== Product roles #roles
>>> -
>>> -Support for per product user groups. Roles can be used to configure
>>> notifications and permissions per product.
>>> -
>>>   === Per product repository #vcs
>>>
>>>   Each product can have different repository (and type) assigned.
>>> @@ -89,6 +169,23 @@
>>>   == Backwards Compatibility #backwards-compatibility
>>>
>>>   The solution has to be compatible with single product solution whenever
>>> possible in order to make possible smooth upgrade paths from previous
>>> installations. This is particularly important for plugins to work
>>> out-of-the-box under the new circumstances or at least to make easier the
>>> upgrade development process for hack authors.
>>> +
>>> +''Product environments'' in proposed multi-product configuration will
>>> act
>>> as the replacement for sibling environments under common parent directory
>>> in [./MultienvParentDir reference multi-environments setup]. They will
>>> ensure that the correct translations will be performed for requests
>>> addressed to resources owned by a product using the
>>> `trac.env.Environment`
>>> API as usual. Components will have access to it by reading `self.env`
>>> attribute (as usual !!!). All this means that from a component
>>> perspective
>>> the very same operations will be invoked , thus plugins adaptation to the
>>> new conditions will be rather smooth. If plugins do want to know whether
>>> they are acting on behalf of a product environment or the global
>>> environment then the following conditional statement would be enough
>>> +
>>> +{{{
>>> +#!py
>>> +
>>> +from trac.env import Environment
>>> +from multiproduct.env import ProductEnvironment
>>> +
>>> +if isinstance(self.env, Environment):
>>> +    # Trac environment
>>> +elif isinstance(self.env, ProductEnvironment):
>>> +    # Product environment ... activate super-powers !
>>> +else:
>>> +    # Unidentified environment object ... aliens & zombies !
>>> +
>>> +}}}
>>>
>>>   == Reference Implementation #reference-implementation
>>>
>>> -------8<------8<------8<-----**-8<------8<------8<------8<---**
>>> ---8<--------
>>>
>>> --
>>> Page URL: <https://issues.apache.org/**bloodhound/wiki/Proposals/BEP-**
>>> 0003 <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003>>
>>> Apache Bloodhound <https://issues.apache.org/**bloodhound/<https://issues.apache.org/bloodhound/>
>>> >
>>> The Apache Bloodhound (incubating) issue tracker
>>>
>>> This is an automated message. Someone added your email address to be
>>> notified of changes on 'Proposals/BEP-0003' page.
>>> If it was not you, please report to .
>>>
>>>
>

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