incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: Managing plugin dependencies WAS: Tests and CI (was: A word on Release 2)
Date Thu, 11 Oct 2012 03:49:38 GMT
On 10/10/12, Branko Čibej <brane@wandisco.com> wrote:
> On 11.10.2012 01:16, Olemis Lang wrote:
>> On 10/10/12, Peter Koželj <peter@digiverse.si> wrote:
>>> 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)
>> That's what Interface class in the component architecture is for . In
>> such a hypothetical case let's limit the discussion to relational SQL
>> DBs . There will be a component that performs actual import / export
>> (let's call it SqlMigrationSystem) an Interface (let's call it
>> ISqlScriptContributor) and multiple components implementing the later
>> (e.g. one for ticket relations, multiproducts , custom per product
>> workflows , users , wiki pages , ...) .
>>
>> So how could all this work . When user decides to e.g. export all data
>> then SqlMigrationSystem relies on Trac core to enumerate all the
>> components implementing that interface . It does not really matter
>> what plugin they belong to .
>
> Etc. Precisely the point. Every plugin that Bloodhound uses for what it
> considers core functionality must implement this interface, or the whole
> export/import story falls on its face.

Well , that's exactly the point , isn't it ? Build a generic framework
and give components some room to make it more specific in many
different ways
;)

... maybe the interface is part of Trac itself ...

> Since these are plugins that the
> Apache Bloodhound project does not control, you either have to ask the
> plugin authors very nicely to implement that interface,

step 1 .

> or do it
> yourself and hope your patches are accepted,

step 2

> or maintain a perpetual
> stack of patches for every core plugin,

that's what we do with Trac vendor branch already , yes ...

> or fork the plugin (for which
> you need a code grant to relicense under ALv2, which ain't gonna happen
> if you couldn't arrange any of the other options with the author),

That depends on the original license . BSD and MIT should not be problematic ...

> or
> write your own plugin providing the same functionality.
>

... well ... afaics you have many options at hand . I don't get it . I
thought you were saying you were locked-in somehow .

You want a tomato . You either buy the seeds , take care of the plants
make them grow , then harvest all of it and then eat it ... or just go
to the supermarket and buy some tomatoes . There's no almighty tomato
.

> None of the above is a showstopper, but the interlocked dependencies
> will make managing feature-stable Bloodhound releases a bit like
> juggling eggs. It can be done, but you'd better not drop one. :)
>

well ... that has already happened . Trac-devs changed component
architecture slightly in 1.0 . Hence ThemeEnginePlugin didn't work
anymore . So we submitted a patch to t-h.o issue tracker .
ThemeEnginePlugin has not been updated since 2 years ago , nobody
cared . We managed to patch our own copy of Trac to make it work
without requiring any changes in ThemeEnginePlugin . That's exactly
what we are all using nowadays , otherwise the new design would not be
a reality . I requested maintainership of ThemeEnginePlugin days ago
and I'm in charge now ... so I don't see the storm coming yet .

<joke>
Titanium eggs never break , sir
:D
</joke>

-- 
Regards,

Olemis.

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

Featured article:

Mime
View raw message