bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Managing plugin dependencies WAS: Tests and CI (was: A word on Release 2)
Date Thu, 11 Oct 2012 20:31:22 GMT
On 10/10/12, Branko Čibej <> wrote:
> On 11.10.2012 05:49, Olemis Lang wrote:
>>> 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 .
> /You/ requested maintainership. How does that help Apache Bloodhound if,
> two weeks or two years from now, you find a new interest in life and
> stop maintaining it?

The same will happen over and over . If there's real interest someone
else will request to adopt the plugin , ask me , I say «it's ok
fellows , I'm devoted to fishing virgin marlins now, Trac no more ...»
, and that's it .

> The issue I see here is that, essentially, the Apache Bloodhound
> community doesn't have any real control over some of the core components
> of Bloodhound-the-product.

I don't see things that way . What I'm trying to explain is that

  1. we have *a lot* of options at hand to handle collaboration with
      Trac-dev and Trac-Hacks
  2. if we'd like to «have real control over all the core components
      of Bloodhound-the-product» then we can , because we'll always
      be able to fork the core itself , and any other Trac hacks we might
      need to make things happen , as long as we select them carefully ,
      which is ok for MIT and BSD licenses .
  3. ... nevertheless it's important to collaborate with them
      (/me included ;) and establish bi-directional relationships .
  4. ... and nothing fatal has happened so far

> That's nothing new in either Apache or open
> source in general; the difference is that BH has so /many/ mandatory
> external dependencies for very fundamental, core functionality.

Read 2. above . That's an obvious consequence of the fact that
Trac-dev and Trac-Hacks have been spending quite many years building
features and plugins , and this project decided to take advantage of
it . Otherwise we could just spend some years rewriting everything
they've done up to this point .

> It's not an engineering problem, it's a management problem; and
> open-source projects are notoriously bad at handling complex management
> problems.

... especially when it comes to pluggable architectures , like Trac's .

> I guess I'm just worried about the long-term stability and viability of
> the project.

TBH I understand , but if you are aware of all the options at hand and
still think this way it's maybe because you have something different
in mind . So what is it about ? Trac-dev joining the ASF ? It seems
that won't happen any time soon . Anything else ?



Blog ES:
Blog EN:

Featured article:

View raw message