incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject [Apache Bloodhound] Proposals/BEP-0003 modified
Date Thu, 15 Nov 2012 03:48:32 GMT
Page "Proposals/BEP-0003" was changed by olemis
Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003?action=diff&version=6>
Revision 6
Comment: [BEP-0003] Moving goals and features to Rationale section , where they belong
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: Proposals/BEP-0003
=========================================================================
--- Proposals/BEP-0003 (version: 5)
+++ Proposals/BEP-0003 (version: 6)
@@ -20,7 +20,7 @@
 
 The evolution on the field of issue tracking systems leads to many requests to support multiple
products in a single environment. This document is meant to gather community consensus on
the implementation of this feature . Besides it is a starting point to envision the impact
on the underlying components architecture and the corresponding development strategies to
get everything done. Ultimately it will explore compatibility considerations for existing
plugins and suggest recommended upgrade paths so that hacks authors will take advantage of
this feature .
 
-[[Image(Multiproduct.png, width=900)]]
+[[Image(Multiproduct.png)]]
 
 == Motivation ==
 
@@ -30,45 +30,65 @@
 
 == Proposal #proposal
 
-The following is a list of proposed features for multi product support in Bloodhound.
+'''TODO'''
 
-=== Product/ticket namespaces
-Product and ticket ID should form a two dimensional namespace, tickets would in addition
to current URL scheme also be addressable through the product URL namespace, namely /ticket/<product>/<id>.
Each product would have a separate numberspace for product ticket IDs. 
+== Rationale #rationale
 
-=== Tickets moveable between products
+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. 
+
+=== 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>. 
+
+==== Tickets #tickets-namespace
+
+Each product would have a separate number sequence for product ticket IDs.
+
+=== Resources moveable between products #migration-resource
+
 Tickets should be moveable between products, old ticket product IDs (and URLs) should be
remembered, making the same ticket accessible through old products namespaces (URLs).
 
-=== Per product search
+=== Per product search #search
+
 By default, search is global. Search and queries should allow search queries to be limited
to specific product.
 
-=== Per product ticket workflow
+=== 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.
 
-=== Product roles
+=== 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 permission scheme
-Permission scheme is defined by assigning permissions (from a predefined permission list)
to specific users or groups. Permission scheme is assigned to a product.
+=== Per product repository #vcs
 
-=== Per product repository
 Each product can have different repository (and type) assigned.
 
-== Rationale #rationale
+== Rejected ideas #rejected
 
-'''TODO'''
+Many interesting ideas have been proposed but not all could make their way into final specification
because of conceptual, practical or other reasons. Below you'll find the most relevant instances
together with brief comments explaining the decision , and maybe links to relevant messages
in [http://mail-archives.apache.org/mod_mbox/incubator-bloodhound-dev/ bloodhound-dev mailing
list archive] .
 
 == Backwards Compatibility #backwards-compatibility
 
-'''TODO'''
+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.
 
 == Reference Implementation #reference-implementation
 
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0003>
Apache 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
View raw message