> >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.
The only developers that will go to the trouble will be those enthusiastic enough to make a contribution, the ones that need the feedback from the general user community. No normal user will go to the trouble. I may be wrong, but that is my belief. > >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. I guess I don't understand why this must be the case. Is there some jakarta apache bylaw that is in effect here? > >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. How tangible can it be? HUGE readme files, disclaimers in the javadoc files. Whatever it takes. > >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. > > Look at the commons-sandbox. The commons-sandbox does not > make releases and > seems darn successful by any yardstick. commons-sandbox is our inspiring example. But let's not forget that the commons-sandbox was created for and is really only used by jakarta committers. By definition, the only people that can contribute to it are committers. My being a jakarta committer, I am already set up with cvs and the build tools, and it is relatively easy for me to download and build the stuff. And commons is really meant to serve the jarkarta projects. The projects have contributed almost all of the base code and the components are primarily consumed by the projects. Given its project and committer focus, commons has a huge amount of built-in momentum. I was hoping that our sandbox initiative would be able to go beyond the committers and enthusiastic developers. I will cede to not releasing log4j-sandbox if it going to be really complicated. But I feel very strongly that it will be a mistake and the initiative will be lost. I look back to the amount of feedback I received when I released built versions of the watchdog code I was working on, before becoming a committer. If that code was just sitting in a cvs repository somewhere, with no real release support, the amount of feedback would have been zero instead of the small number of comments I received. I have no illusions on this point. It is hard enough trying to get feedback on initiatives that are part of log4j core. Off topic from this, if we do release sandbox, then I would like to see test cases as part of the requirements to move code into the "stable" area. We will accept any contribution and place it in the "contributors" area. If the contributor wants to move it to the "stable" area (the part that uses the log4j package space), then at least one comprehensive test case must be submitted. Just an idea. -Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
