On 10/10/12, Branko Čibej <[email protected]> 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 ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
