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.
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.
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.
--Peter
On 3/26/02 4:54 AM, "Andrew C. Oliver" <acoliver@apache.org> wrote:
> 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>
>>
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
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.
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.
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.
--Peter
On 3/26/02 4:54 AM, "Andrew C. Oliver" <acoliver@apache.org> wrote:
> 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>
>>
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>