jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: Improving the accessibility of the Jackrabbit core
Date Thu, 07 Sep 2006 06:44:06 GMT
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.

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


View raw message