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 <[email protected]> wrote: >> * Some of the files in Bloodhound's modified copy of Trac core contain >> "Licensed to the Apache Software Foundation" headers. >> (trac/utils/tests/introspection.py and trac/util/introspection.py 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".) > 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, Ethan
