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
