bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jucovy <>
Subject Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
Date Mon, 13 Aug 2012 14:44:20 GMT
First, in general: since Greg at least clearly misunderstood the spirit of
my message, let me clarify a few things.  My intention was certainly not to
block or dictate anything.  *My vote* represents *my opinion* (it was made
with full knowledge that it carries no formal weight) and everything that I
said was a recommendation and no more.

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.

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.  In my experience it is
much, much harder if those goals aren't built in to the development
practices from the start, and if evaluating progress against those goals
isn't tied to the project's existing lifecycle.  Among other reasons, this
is because maintaining upstream technical-and-community compatibility will
NEVER be anyone's first-order priority -- basically by definition, since
it's both more abstract and longer-term than any particular feature, bug
fix, milestone, etc.

Hence my questions: my point was not that comprehensive answers should be
provided before the first release, but that the questions should be raised
before the first -- and every subsequent -- release, because release-time
is the most (only) natural moment for evaluation.

I'll respond to a few specifics below.

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

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

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

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.  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) which would have to(?)
be revoked in case of upstream contribution.  This, again, seems like a lot
of artificial barriers to integration.  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.

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.

>> How often do Bloodhound's developers merge in upstream
>> changes, and what is their policy for deciding when to merge upstream
>> changes?
> … I think this deserves a whole new thread forked from here , if you
follow .

I agree, FWIW.

> The only thing I suggest is
> to create a ticket in a particular milestone (e.g. upstream_reject) to
> watch for this , because there's a chance that e.g. three years later
> Trac evolves and fortunately there will be a way to do the same thing
> using new or modified APIs .

I agree with this too -- it would be nice to find these kinds of issues
through structured ticket queries in some way.

> 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.  Having different workflows for
patching Trac core and patching plugins seems like an artificial barrier to
implementing "the most correct" fixes.  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.

> 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?  Do your other instances?  If so, does it really *need* to
iterate over the extension point in its initializer and not in a lazily
evaluated property?

Anyway, the specifics of this too can be revisited in another thread and at
another time.

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

> OTOH we *REALLY* needed ThemeEnginePlugin in order to customize web UI
> so , I repeat the question ... what shall we do ? wait 2 more years in
> order to release 0.1.0rc1 ?

No.  I did not mean to suggest that removing this core patch should be a
prerequisite to releasing 0.1 -- just that the questions "Is this core
patch necessary?", "What can we do to make it no longer necesssary?" and
"What progress has been made to remove those patches?" should be asked
before the first and every subsequent release, as well as the
meta-questions about the infrastructures and workflows that facilitate
answering those questions.  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.

Hope this clarifies,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message