On Sep 6, 2006, at 4:14 AM, David Nuescheler wrote:
Personally, I believe that for example a "restore" facility has to be
buried deep down in the core and therefore the code has to comply
with the high quality requirements that we have for code in the core
and for the seasoned "Jackrabbit experience" of a developer.
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.
In my mind your experience with developing very close
to the "heart" of Jackrabbit should not lead us to opening
up the core so inexperienced Jackrabbit developers can
contribute, but it should help us realize that we have
very high requirements for Jackrabbit developers that make
modifications to the core.
I don't think you understand. This is an Apache project and anyone can
contribute to any part of it. 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.
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.
....Roy
