Hi Roy, Thanks for helping me crystallize my thoughts and trying to sharpen my statements ;)
That is why each of the core developers has veto power over the code. If we want to ensure that every line is adequately reviewed, then ask for the core code to be governed by the RTC (review-then-commit) rule. Note, however, that such a requirement will extend to all commits on that part of the code.
I would never doubt that the ASF has all the machinery in place to ensure code quality on levels that are way beyond what Jackrabbit might ever reach. I think an open source landmark project like the HTTP Server is proving this in a very impressive way.
I don't think you understand. This is an Apache project and anyone can contribute to any part of it.
I would like to apologize, it was not my intention to imply or suggest anything different. Let me try to rephrase my personal feeling on this subject as follows: Inherently in any piece of software there are certain areas of the code that are used and run more frequently and others that are used less frequently. In my experience the pieces that are at the core of any piece of software have a greater impact on the overall stability and performance and changes may have a side effects that are far reaching. Also the core pieces tend to be the most mature code, in many cases some of those source files have been updated more frequently. Within the realm and maturity of the Jackrabbit codebase I think the best maintained and most mature code that we have is in the core. Which is both obvious and good. (And just to be clear, "well maintained" and "mature" do not imply an architectural statement) The essence of my post should have expressed (and we may very well disagree on that) is that biggest stumbling blocks in the uptake of Jackrabbit adoption are not complexities or deficiencies in the core architecture, but the issues that Dave mentioned in his post earlier in this thread and I wanted to find out if others have a different opinion on that.
The degree of review we require of those contributions is decided by the PMC (our committers). We can increase the requirements on review of the core code and we can separate compatible and incompatible changes into versioned branches, but we cannot ask of others what we do not accept of ourselves.
Agreed.
In my opinion, the core code continues to evolve as people try to do larger and more expressive things with Jackrabbit and apply JCR to real problem sets. We need to welcome that and change things based on their technical merits, not any preconceived notions of how much a person knows about the current (highly opaque) core architecture. Most likely, this will mean simplifying the core by removing or refactoring some of the spaghetti dependencies.
When I read your comment, I wondered what I may have said that made you think that I am opposed to that. I realized that I completely failed to share my thoughts about "the SPI" and how that might stimulate a more modular and more transparent architecture of the core. I will (re-)initiate a separate thread on that. Sorry for the confusion.
One of those things that will change is the degree of extensibility, since that is the heart of any successful open source project and Jackrabbit isn't even halfway there yet. I am sure that others with fresh energy will see new ways to solve the same problem that will not be burdened with the legacy decisions that we made for one reason or another. When those ideas are presented, they will be subject to intense scrutiny and adopted based only on their proven benefits. They will not be judged based on who wrote them or how much time they spent writing the initial core code.
I couldn't agree more. regards, david
