Re: Managing plugin dependencies WAS: Tests and CI (was: A word on Release 2)

[Olemis Lang <ol...@gmail.com>]

On 10/10/12, Branko Čibej <br...@wandisco.com> wrote:
> On 11.10.2012 05:29, Olemis Lang wrote:
>
[...]
>> 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.
>

I c ... I've been following some ISO activity and consulted an ISO
expert . I really have not got any useful reply so far . So maybe
we'll have to invent this wheel
:P

> 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.

Now I understand what you are looking for .

> 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

Considering the pluggable nature of Trac it turns out (to me) that the
most appropriate format should be some kind of archive containing
multiple files for each kind of data ... or something like XML . IMO
this is related to another subject , which is the REST API . If such a
feature is incorporated then resulting data representation (format
does not matter) should not depend (too much) on underlying DB backend
. Migration should consist in accessing an URL in source environment
and POST resulting data onto target environment ... more or less ...

> that doesn't even have to be SQL-based (think distributed
> databases).
>

I get it , though major refactorings have to be applied to make Trac
work with non-SQL DBs technologies .

> 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.)
>

understood

>> 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.
>

<joke>
well ... English invented the word ;)
</joke>

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: