lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Serebrennikov <>
Subject Re: Action Item Vote Request
Date Tue, 26 Mar 2002 21:17:10 GMT
Peter Carlson wrote:

>Hi all committers,
>Here are some questions to vote on. If you don't like or understand the
>description, please vote -1, if you don't care vote 0, if you like the idea
>and would be willing to contribute some time please vote +1
>Each item below needs +3 items to vote with no -1 votes to pass.
>1) Create a contributions area as part of the Lucene CVS. This area would be
>used to bring together submitted to the Lucene mailing list (with permission
>from the submitter). The code would need to be repackaged (i.e. Give it an
>org.apache.lucene.contrib package), licensed (add the apache license), added
>to the  "build-contrib" target of the ant build script.
>There are a lot of great contributions out there that may or may not become
>part of Lucene's core build. I am +1 and am willing to set this up and help
>maintain it.
Given other's feedback, I think the best way to handle this might be to 
store these as simply tars or zips with some release notes by the 
original contributor. This way they do not have to be built (and 
compatibility maintained as the code evolves), and yet they are 
available to those who have a need and a willing to experiment and maybe 
adapt them to the use with Lucene in their project (if such adaptation 
becomes needed over time). The major benefits over a simple list of 
links to other pages is that (a) once contributed these resources remain 
available to anyone interested, and (b) people without ability to host 
their own download sites can still contribute (I know, I am one!).

>2) Create a scratchpad area in the Lucene CVS
>(org.apache.lucene.scratchpad). This area would be focused on creating new
>parts of the Lucene core in an experimental mode. This code would be
>considered unstable and unsupported. If a part becomes stable and is desired
>to be moved into the Lucene core build, it must be approved through a
>committers vote (+3 votes).
>This area would be a place that committers can join together on new projects
>/ experiments so they do not interfere with the regular Lucene development
>process and still get collaboration.
>My vote is 0 for this area. I think its a good idea, but I don't have any
>current plans to help with it.
+1. I think this is a great idea!
As far as details, I'm 0 on build target or no build target (just don't 
know what are the pluses or minuses of this), except maybe this: what 
happens if the people involved in one sub-effort under the scratchpad 
area loose interest for a month, and meanwhile the main codebase evolves 
such that that scratchpad sub-effort area no longer compiles? I think a 
good answer to this is that pieces of scratchpad can be tarred up and 
moved into "contrib" area if active development stops on them. And 
viceversa, projects on the "contrib" area that people want to make 
current and bring up to speed can be untarred and inserted into the 
"scratchpad" for common hacking and preparation for inclusion into the 
main codeline.

The main benefit I see here is a place for people to collaborate on code 
without affecting others until ready. A kind of a branch without a 
branch. One question - can commit access to this area be controlled 
separately? If not, I'm still +1, but it might be nice.

>3) Adopt a more formal release plan.
>    a)Beta means feature freeze
>    b)Release candidate means code freeze (unless bugs)
>To move into a beta or release candidate stage, you must a vote by the
>committers (+3 votes).
>I am willing to help with the build process. I will work with Doug to help
>handle these activities.  This also would include updating the web site.
>I am +1.
+1, but I won't be able to help here at this time.

Dmitry Serebrennikov

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message