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: Managing plugin dependencies WAS: Tests and CI (was: A word on Release 2)
Date Thu, 11 Oct 2012 04:08:42 GMT
On 11.10.2012 05:29, Olemis Lang wrote:
> I don't think so ... unless that's a goal in first place . The
> concepts in track are the same in Jira , in the end . You have tickets
> , users , changesets , comments , permissions ...
>
> I don't see why CSV , XML , iCal , ... formats will change due to the
> fact that somebody implements some component in BH . Maybe it turns
> out that there is no standard format to exchange e.g. tickets ,
> permissions , ... between different systems . That's a problem much
> bigger and substantially different than anything related to BH
> architecture .

Exactly. XML or CSV are not what I would call a common export format for
issue trackers. Either one can be used as a /text representation/ of
such a format, but that hardly solves anything, because all the
semantics are missing.

> If there's a standard exchange format there's no problem to implement
> a Trac component importing / exporting data by following its rules .

The only "standard" that I'm aware of isn't really a standard, it's just
Jira's XML export.

What I believe BH should be aiming for, eventually, is to be able to
export all the data required for whatever the defined core functionality
is to some common format -- it doesn't matter what that looks like,
except that it very likely shouldn't be a SQL dump -- such that another
BH instance can import it in a way that preserves /all/ data. That's not
just tickets but also user accounts (if managed by BH, not e.g. LDAP),
user preferences, global and per-user stored queries, notification
settings, etc. etc. Essentially everyting you need to replicate a whole
Bloodhound installation to, for example, a completely different database
backend that doesn't even have to be SQL-based (think distributed
databases).

Once you have that, importing data from any other issue tracker is a,
hm, "simple" matter of writing an exporter to that common format. (I use
"common" in a fairly narrow sense here; it can be BH-specific, but has
to be completely independent of any conceivable database backend that BH
might someday support.)

> Like I just said , it doesn't matter what package it belongs to
> exactly . It just has to be there and enabled .

I think we're fundamentally disagreeing on the complexity of the "just"
in that last sentence.

-- Brane


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


Mime
View raw message