logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <mwom...@apache.org>
Subject RE: moving filters to log4j-sandbox
Date Wed, 05 Feb 2003 06:38:21 GMT

> Whatever is in the sandbox cannot/should not be released at all! The
> point of the sandbox is to let developers unleash their talent without
> being limited by the committers. I think for example that Jacob should
> have write access to the log4j-sandbox so that he can continue working
> on selectors and servlets. Eventually those components should be
> merged with log4j-proper and Jacob granted full commit privileges.
> I would oppose any attempt to make the log4j-sandbox a less reliable
> version of log4j.

1) The sandbox will never be a replacement for core log4j.  It will always
be a dependent supplement to the core log4j release.

2) If we do not package and release the sandbox in some manner, NO ONE will
ever bother to use the classes.  VERY FEW users will take the time to get a
copy of the cvs tree, get copies of all the tools needed for doing a build,
figure out all the build configuration points, and then build the jars.
Even if they do this, there will be a sizable group of them that complain
that their companies want an "official" release of the code to use and where
can they find it, etc.

3) I completely agree that ultimately the sandbox is the place for an
enthusiastic group of log4j developers to contribute useful, possibly
experimental, classes that will evolve over time.  Eventually these classes
will be admitted to the core release (and their developers potentially made
committers) as issues and designs are evolved and debugged and their
usefulness is proven.  The best way to get feedback in order to evolve the
code is to make them available to real log4j users.  This will only be
accomplished by #2.  We can be very loose with accepting contributions.  I
do think that some slight control can be applied to organize contributions
by nature, stability, experimentation, etc.  Decisions in this regard can be
opened up to votes including non-committers subscribed to the dev list.

4) Given #2 and #3, we need to set the expectations for sandbox releases.
Unlike the core log4j releases, classes in the sandbox are allowed more
flexibility to change, perhaps very dramatically.  No guarantees are given
that the interfaces and methods will be exactly the same from release to
release.  Yes, end users may be uncomfortable with that, but that is the
nature of the sandbox.  Just because something is in the sandbox does not
mean that it is unstable or buggy.  It may not have all the testing applied
or all the issues worked out, but it is deemed useful and workable.  It is
just allowed to change to a greater degree than the core log4j release.

5) We can package the various parts of the sandbox in different ways, with
the appropriate disclaimers.  There may be a contributors area for odds and
ends.  There may be a "core" sandbox area where classes are named in the
log4j package space (like filter, selector, and servlet are today).  The
core area may be deemed more "stable" than the contributors area.  There may
be another area for highly "experimental" classes.

6) Because the sandbox is a dependent supplement to the core log4j release,
and because its purpose is to make available and evolve useful classes, it
can be released on a more aggressive schedule than the core log4j release.
Where we might only have 1 core release a year, we might have 3 or 4 or more
releases of the sandbox in the same time period.

I hope that makes sense.  I feel very strongly that if we do not release the
contents of the sandbox in some manner, with appropriate disclaimers as to
its dynamic and experimental nature, then much of the effort, meaning, and
benefit of the sandbox will be lost.  The goal is to encourage and foster
participation by the larger log4j community.  They need to be provided with
something concrete, like a periodic release of the sandbox, so that they can
participate by using it and giving feedback.  The developers will need this
feedback in order to evolve and prove their designs and code.  Committers
will need to see this evolution in order to better judge the merit of the
code and the interest/merit of the developer before committing it to the
core release.


To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message