lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: Development issues / processes
Date Tue, 26 Mar 2002 12:54:23 GMT
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:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
> 
-- 
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:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message