incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@wandisco.com>
Subject Re: Tests and CI (was: A word on Release 2)
Date Thu, 11 Oct 2012 02:41:39 GMT
On 11.10.2012 02:12, Gary Martin wrote:
> On 10/10/12 18:26, Peter Koželj wrote:
>> I admit it, some of my fears could just be the cause of the fact that
>> I am
>> not familiar with Trac plugin architecture and the Trac plugin
>> ecosystem as
>> a whole yet.
>>
>> Just a few use cases for quick "does it float" test:
>> 1. Let's say we adopt some plugins for multiproducts, ticket relations,
>> data import/export and so on...
>> 2. Then we want to add user (admin) defined ticket relation per product
>> 3. And then we want to support custom ticket workflows per product
>> and per
>> ticket type
>> 4. And now we want the ticket import/export from/to Jira to work across
>> Trac and all other plugins (including ticket relations, multiproducts
>> and
>> custom per product workflows plugins)
>> 5. Add white labeling across Trac and all other plugins
>> 6. Implement new search query language that will understand tickets,
>> products and relations
>> 7. Add REST API's for all of the above
>> 8. ...
>>
>> Now, all this plugins (products, relations, import, export, search,
>> white
>> labeling, new search...) will either have to know filthy little details
>> about each other (complex inter-plugin dependency) or some super heavy
>> shifting in the plugin interface will be necessary. And that super heavy
>> shifting will have to be pushed back to Trac (if it wants it) and
>> only then
>> to these plugins or create new Bloodhound plugin API on top of Trac
>> plugin
>> API and then request plugin authors to support it.
>>
>> Am I missing something?
>
> I am not sure that I see the same difficulties. It seems a pretty
> normal thing for a program to be divided into components in such a way
> that keeps filthy details hidden. All we are doing here is allowing
> the set of components to be distributed between core trac, bloodhound
> plugins and external plugins. This is achieved through Trac and
> plugins defining interfaces, with components then being able to
> implement the interfaces and/or iterate through components that
> provide the interface.
>
> So far I have found little reason to put any "super heavy shifting"
> into trac itself as they appear to have provided enough interfaces to
> allow for some fairly complex subverting of standard trac processing.
> The namespacing for multiproducts is a case in point where, so far, it
> appears to be achievable outside of trac. If it is not possible to do
> all that we want to with, say, per-product configuration or workflow,
> it might be that we will need to introduce a new interface to Trac to
> allow us to take over processing at the appropriate time but I am
> hoping that this will not be necessary.

The point Peter is trying to make is this: if we take as an example the
multiproduct plugin:

This plugin has to change the trac database schema (or rather, add a
more-or-less independent namespace mapping to the existing schema).
Consequentially, plugins must be allowed to either update the core
schema, or create their own additional schema. Whichever it is affects

  * database schema upgrades (from any older version to any newer version)
      o either each plugin has to have its own schema upgrade mechanism
        -- a nightmare, or
      o the plugin API must define unified schema management protocols,
        wich /all/ plugins that fiddle with the schema have to conform to
  * data export/import
      o as above, either each plugin handles its own export/import (and
        incidentally defines its own export format), which implies that
        anyone who wants to write an exporter from another issue
        tracking system to Bloodhound's export format has to know
        exactly which plugins are in fact part of core Bloodhound; or,
      o the plugin API must define a common event streaming protocol
        that can be converted to a generic export format; which does not
        seem trivial to me.

As another example, a "new search" plugin would conceivably allow
defining event notification triggers based on the results of a custom
query having changed. Any export format has to have a way to represent
this (if only because JIRA has this feature and you'd eventually want to
be able to import these definitions if BH achieves feature parity in
that respect).

Almost every new feature that Bloodhound adopts and implements via a
plugin affects with the goal of creating a common export format, a
concept that trac does not have and therefore isn't likely to be
supported in the plugin API.

-- Brane


-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download


Mime
View raw message