logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: moving filters to log4j-sandbox
Date Wed, 05 Feb 2003 10:22:08 GMT
At 22:38 04.02.2003 -0800, you wrote:
>Ceki,
>
> > 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.

I also understood that the sandbox would be a log4j supplement.

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

A small percentage of a large number can still make a few dozen people. 
That is more than enough to get valuable feedback. Moreover, feedback from 
people can who are able to a CVS checkout and run ant is likely to be 
better than someone who is unable or unwilling to perform those tasks.

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

Yes, we can be lax as long as the contents of the sandbox are *not* for 
release. If the sandbox is just a log4j supplement, then it will demand the 
same maintenance costs as log4j itself.

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

There must be a tangible means for users to understand that the sandbox is 
for experimental software. Enclosing a number of jar files in a zip file 
called log4j-sandbox will not convey the same clear cut impression.

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

Please let us keep it simple.

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

Look at the commons-sandbox. The commons-sandbox does not make releases and 
seems darn successful by any yardstick.

>-Mark

--
Ceki 


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


Mime
View raw message