On Mon, 2002-03-25 at 02:36, Peter Carlson wrote: > I still think that the following issues should be figured out for the Lucene > project. I don't know how this works with an open source community, but > since Doug is the project lead, I think he should weigh in on these issues. > I think we have people willing to do the work, I think we just need to all > get on the same page. >
I think we should just say yay or nay to the scratchpad issue and get rolling. We had plenty of discussion a couple months ago. Lets get rolling. > Questions: > 1) Should Lucene put 3rd party contributions into the projects CVS under a > contrib area? Define "3rd party" > 2) Should there still be a contributions page? no opinion. > 3) Should there be a scratchpad area which basically provides an unsupported > testing ground for new ideas and code? Yes! And the application extensions should go there until they are stable enough > 4) Should there be a sub-project for the web crawler project that is being > discussed? no. "sub project" implies some order of magnitude greater than I think this is and we sure as heck don't want another mailing list for it. To be honest I don't really care if you call it a subproject or not. I more think of this as a package with a different build target. If that's a subproject....cool. > 5) What is the release process for Lucene. That is what do the different > stages mean (alpha, beta, release candidate?) > > > My thoughts. > > 1) We should have a contributions area which has code that has been tested > and been re-packaged to fit into the org.apache.lucene.contrib framework. If > this code then becomes part of the default distribution then great. > But this is different from what we're doing. We've got code contributions that we're refactoring to meet a already submitted specification. This is different then an autonomous donation. > 2) I think yes. I think the contributions cvs area includes repackaged code > that is unsupported. The contributions web page includes links to code that > is created by other and is either not repackaged, or does not make sense to > include as java code (i.e the javacc link, or the pdf converter or the > isogen xml indexing code). > > 3) I think since everyone is working in a very distributed environment, it > would be nice to have a place to try out ideas and have people comment / > contribute to the code without making it part of Lucene. So I would like to > see this area added for areas of Lucene that someone wants to change. An > example might be serializing the Analyzer (some people want it, other may > not and so it would be nice to see how well it worked in a test unsupported > environment). > +1 + the application extensions. This is just an area to build and refactor until we're ready to move into the regular section and have a separate build target. > 4) If people are really going to create this then yes. Create a component > name for it and start the project happening. I think since it will be all > new code and the Lucene API is very stable, it should be a different sub > project on its own time frame. > > 5) Some ideas on a Lucene release staging process. > Stage 1 (Design) - determine and design new features for next release (this > might change on the way but there should be a defined set) > Stage 2 (Development) - Work on new features > Stage 3 (alpha) - All new features exist, but there are bugs. May fail some > unit testing. Feature Freeze (this may be difficult in a open source > environment) > Stage 4 (beta) - No show stopping bugs and completes all unit tests. Request > outside developers to start working with release. Fix bugs. > Stage 5 (release candidate) - All know bugs have been fixed and the product > is presummed stable. A wider audience tries the release. If not bugs are > found in a 5? day period, the release is goes final gold master. Source code > freeze unless bugs found. > Stage 6 (Gold Master) - The release is final. > > Start the process over again. > > > What do other think of these issues / processes? Any suggestions are > welcome. > Anyhow, I think what I'll do for now is see if I can get a commons subproject called luceneappext and start this there. When you have all the issues / processes worked out we can work this in then. -Andy > --Peter > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
