bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Tue, 14 Aug 2012 02:05:54 GMT
Hi !

On 8/13/12, Ethan Jucovy <> wrote:
> As I've said before, I am not questioning whether the Bloodhound developers
> *intend* to fork Trac.  My concern has always been whether a fork will be
> established as an unintended consequence.

Considering the work we have made so far I'd rather say that the main
goal has not been to fork Trac . We've basically done that in spite of
been able to customize our own copy as a last recourse needed by new
features without waiting for trac-dev to commit them upstream . I
think I'm accurate when I say that at present >95% of the code belongs
in the plugins ...

> Building a product on top of a system that's already more of an application
> than a framework and that has a large plugin ecosystem, without fracturing
> the community or breaking compatibility, is hard.

... hence Bloodhound , at least the way it stands today , will not
cause any harm to Trac community harder than any other plugin due to
the fact that it is basically *a set of plugins*

> On Fri, Aug 3, 2012 at 3:56 AM, Olemis Lang <> wrote:
>>>  * Some of the files in Bloodhound's modified copy of Trac core contain
>>> "Licensed to the Apache Software Foundation" headers.
>>>  (trac/utils/tests/ and trac/util/ are
> the
>>> ones I've noticed, but I didn't grep the repository.)
>> well I did , and this is what I found (a summary of course ;)
> Thanks, I appreciate that.


>> 4. finally consider the fact that we have applied bigger
>>    modifications on other files and did not change license
>>    headers at all .
> Point taken.  I guess I wonder then why newly created files should be
> licensed differently.  (But I think I answered this question for myself
> below: "original code".)

Maybe. Just notice that we do not create new files deliberately . For
instance , if there's a new utility function for dates and times ,
then it should be included in `trac.util.datefmt` module . If function
processes text then it should be included in `trac.util.text` module ,
... and so on ...

>> 1. what's the reason for so much noise ?
>> 2. if we suggest a patch upstream containing a whole
>>    new file we did from scratch . Why is it that you
>>    complain about it whereas Google's source code
>>    released under the terms of the same license
>>    is accepted with pleasure ?
> Presumably in the excanvas.js case the file already existed with that
> license when Trac's developers chose to integrate it, so there was no real
> chance of it being otherwise.
> But also note that excanvas.js is distributed under the Apache license; it
> doesn't say "Licened to the Apache Software Foundation" (AFAIK) - see
> below.

Of course not . It says «Copyright 2006 Google Inc.» .

>> 3. in case we are the original authors (the project I mean)
>>    like in (2) why can't we propose a file with AL v2 header ?
> This was discussed in a lot of detail in the original thread on trac-dev
> about Bloodhound; it's not that you *can't*, it just creates avoidable
> complications, either for the developers or for later consumers of the
> code, in case of integration.

yes , I recall

> I was not very clear in my original message though.  The "Licensed to the
> Apache Software Foundation under one or more contributor license
> agreements" header is not itself an Apache license.

AFAIK , yes it is when combined with the rest , considering the fact
that the license makes space for that to happen . Nonetheless I'm not
an expert , so I won't follow beyond that comment .

> I'm not sure what it
> actually means but I my understanding is that it indicates, as well as an
> Apache license, a copyright assignment to ASF (presumably necessary because
> it is original code in ASF's subversion repository)

Compared to , in there you have an explicit copyright
statement and ...

> which would have to(?)
> be revoked in case of upstream contribution.

... afaics it was not revoked at all ... and you can upgrade (already
done ? guess so ...) at any time .

> This, again, seems like a lot
> of artificial barriers to integration.

so I repeat , what's the matter in this particular case.

> But other messages in this thread
> seem to say that this will not be a problem and/or will be moot in the case
> of these specific files.

*seem* => interpretation => may be not accurate => not actually
happened => why bother ?

> That said, this set of complications was one of the factors in the original
> decision(?) by Bloodhound's developers to work on Trac core modifications
> outside the ASF SVN (e.g. Github) and [therefore be able] to keep all
> modifications BSD-licensed; hence my asking why the developers changed
> their mind, and questioning whether the added convenience should really
> outweigh the ensuing headaches.

it's a conspiracy . trust me .

Please focus on this now .

Q - Have we proposed any patch upstream ?
A - No
Q - Should we ?
A - yes
Q - Is there any part licensed under ALv2 a candidate
     to be committed upstream ?
A - *NO*

So I ask , what's the reason for all that noise ?
nothing like this has actually happened , and nothing similar has been
discussed with trac-dev yet . Continuing with this is kind of a
science fiction movie for the time being . Who knows ... might be a
good subject later

>> 1. user reports an issue in Bloodhound issue tracker
>> 2. we analyze it and determine if it's an error in third-party plugin
>> 3. we forward the issue to plugin's issue tracker and close
>>     Bloodhound's as wontfix , providing all the details so that
>>     it will be possible for users to follow the discussion in
>>     forwarded ticket page .
>> 4. we are not responsible anymore
>> ... at least that's the way (I think) it should work as long as we do
>> not include code for third-party plugins in ASF repository and take
>> responsibility for maintaining it .
> Well, this seems odd to me -- I would think that it would be easier, in
> both the short term and the long term, to use vendor branches of plugins as
> well as a vendor branch of Trac itself.

I think you misunderstood my answer , mainly by ignoring this phrase *
as long as we do not include code for third-party plugins in ASF
repository *

> Having different workflows for
> patching Trac core and patching plugins seems like an artificial barrier to
> implementing "the most correct" fixes.

There's no way I said that . The phrase above means «we can not take
responsibility for improving all plugins out there, hence we'll
forward issues to original plugin authors if we determine it's beyond
the scope of the project» . I didn't want to entangle with the case
when a patch for plugin is required , and I won't now either ...

> But I may be assuming a deeper
> dependency on select plugins than Bloodhound currently has; maybe this will
> happen as soon as plugin patches are needed.

... at least until we have an scenario like this

>> TBH plugin code was not in error , I mean there was no semantic nor
>> even a programming error . In few words the answer was «we changed
>> Trac code for a good reason and what everybody used to do before will
>> not work now . you have to over-complicate your code and stick to our
>> new policies (<= do not enumerate extension points in component's
>> initializer if it implements target interface)» . I honestly don't
>> agree with trac-dev decision so , in the end we decided that such a
>> situation (i.e. enumerating ExtensionPoint objects in initializers of
>> classes implementing target interface) will happen quite often in our
>> code and preferred not to over-complicate plugin code , use locks ,
>> etc, etc (oh my !) ...
> I think this indicates the gray area between patching core as a "last
> recourse" and patching core because you don't agree with core's approach.
>  As you say, there are other ways to do this -- they're just
> "over-complicated," or require rethinking your solutions.  I don't think
> it's very common for components to implement an interface that they also
> have as an extension point; does ThemeEngine really *need* to do this to
> function?

ThemePlugin does so in order to ensure that default theme will always
be available if theme engine is active as a single component needs to
be activated for both cases.

> Do your other instances?

fwiw we have some other cases , and this also happens .

> If so, does it really *need* to
> iterate over the extension point in its initializer and not in a lazily
> evaluated property?

the point here is ...

Q - Can we fix that without modifying ThemeEnginePlugin
     source code?
A - No
Q - Can we take ownership ?
A - Not yet (... like I already said ...)
Q - Do we want to wait 2 more years for this problem
     to be fixed ?
A - Hmmm ... no
Q - The semantics of enumerating an entry point descriptor
     are they really so particular so as to allow for doing so
     everywhere except in component's initializer under
     very particular circumstances ?
A - Definitely not . People's been doing so since long time
     ago and it worked . The fact is that some modifications
     included in
     Trac=0.12 break entry point semantics by raising a
     completely odd infinite recursion error. Suddenly
     the simple operation of listing components in a collection
     becomes a matter of mutexes , locks , thread
     synchronization, lazy access , properties ... you
     can even add your favorite daemons to the list .
     We decided to stick with common and not to break
     plugins code .


>> Nonetheless there's a ticket opened somewhere
>> in ThemeEnginePlugin issue tracker. If we ever manage to find out a
>> generic , clean and simple solution not relying on a core patch , we
>> will try to revert our changes and use it once we test everything is
>> ok with it . The way I see it that has not happened yet .
> FWIW this is exactly the sort of thing that would benefit from a milestone,
> keyword or other piece of structured metadata, including the reference to
> the ThemeEngine ticket.


> My "-1" referred to the licensing and code
> location aspects, and to the fact that these questions had not yet been
> raised and discussed, and no more.

Oranges and apples . That's the way I see it *now* . Even if you might
be right regarding the fact that there's a lot more to do , etc , etc
... I don't see why that's necessary to release o.1.0-rc1 . I do see
these subjects might be addressed before graduating the project from
Incubation process . AFAIK that's not an immediate milestone right



Blog ES:
Blog EN:

Featured article:

View raw message