Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Errors-To: <carlson@bookandhammer.com>
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Sun, 24 Mar 2002 23:36:11 -0800
Subject: Development issues / processes 
From: Peter Carlson <carlson@bookandhammer.com>
To: Lucene Developers List <lucene-dev@jakarta.apache.org>
Message-ID: <B8C4136B.3CC6%carlson@bookandhammer.com>
In-Reply-To: <1017016873.11829.1619.camel@linux2.superlinksoftware.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

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.

Questions:
1) Should Lucene put 3rd party contributions into the projects CVS under a
contrib area?
2) Should there still be a contributions page?
3) Should there be a scratchpad area which basically provides an unsupported
testing ground for new ideas and code?
4) Should there be a sub-project for the web crawler project that is being
discussed?
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.

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

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. 

--Peter


--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>