Mailing List Archive

> 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

I think Jakarta's voting system differs a little, doesn't it?
If I'm correct maybe we should stick with a 'standard' voting scheme
instead of inventing our own and repeating mistakes of people who
already went through this for us to learn from.
If I'm incorrect, please ignore.
This is constructive criticism! :)

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

0.
What I really feel is that this would be nice, but only if somebody is
_really_ going to do this (stronger than 'help maintain').
I'm not sure that this should be a replacement for contributions area
on the site that Peter currently maintains, because it looks like it
would be very hard to always try to sync the Lucene-adapted version of
the contributed code with the original code that the author may still
be working on.
If you already thought of that and have ideas, please share them.

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

Before we can really vote I think we need to have a common approach to
this. One idea proposed by Andrew was Jakarta Common 'luceneappext'
(long word, how about just LuceneApps?) subproject. This would mean
org.apache.commons.luceneappext.
On the other had Andrew said that he thinks of scratchpad as only
another build target, so that implies keeping this under Lucene's
Jakarta project.
What you are suggesting is keeping it all within Lucene repository,
etc.
So which one is it? :)

I think it may be easier to go with Jakarta Commons Sandbox, but I
think the purpose of that Sandbox is that when code matures it migrates
to Commons proper, and not elsewhere (not to Lucene). I could be
wrong, maybe there are examples/subprojects that can easily show that
I'm wrong :). In that case I'd vote for Jakarta Commons Sandbox
approach, as I feel that it will be more clear that this is
experimental/work-in-progress code.

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

I am +1 on slightly more formal release plan, or rather, slightly more
regular release schedule. I remember you suggested a release a month
ago, but nobody really responded to your email (nobody cared?), and the
release never happened.
I am -1 for making it as rigorous as you suggested in an email
yesterday, but something like the above sounds fine, so +1.
We can also look at how other Jakarta projects handle this, pick some
that we think are solid, and use them as examples.
Who wants to volunteer to do that - iff this is a good idea?


Finally, let me just add this, I'll make it short.
I'm +1 for minimizing beaurocracy :)
When people have constructive ideas, time, energy, and desire to
contribute I'm all for supporting that. Not blindly, but not slowing
them down too much. These things come in limited quantities,
unfortunately :(

Anyhow, my 0.02 lek.

Otis

> 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


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

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

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

+1 if i can find it, I have some old contributions from developers on my
other computer from long back when we were still @ sourceforge that I would
like to put in.

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

0 I dont know :)

> 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 here too.


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

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

+0 - its not relevant to me


> 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 and my original message said "I'll do this" -- so I'll do this.


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

+0 - I have no strong feelings about this one way or another and have no complaints with the job Doug has done up to now on this. The release plan should not affect the scratchpad as its "experimental" always.

-Andy

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

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


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

> Before we can really vote I think we need to have a common approach to
> this. One idea proposed by Andrew was Jakarta Common 'luceneappext'
> (long word, how about just LuceneApps?) subproject. This would mean
> org.apache.commons.luceneappext.
> On the other had Andrew said that he thinks of scratchpad as only
> another build target, so that implies keeping this under Lucene's
> Jakarta project.
> What you are suggesting is keeping it all within Lucene repository,
> etc.
> So which one is it? :)

> I think it may be easier to go with Jakarta Commons Sandbox, but I
> think the purpose of that Sandbox is that when code matures it migrates
> to Commons proper, and not elsewhere (not to Lucene). I could be
> wrong, maybe there are examples/subprojects that can easily show that
> I'm wrong :). In that case I'd vote for Jakarta Commons Sandbox
> approach, as I feel that it will be more clear that this is
> experimental/work-in-progress code.

Generally the commons projects aren't "scratchpads" for extending the functionality for a particular project. Anyhow, that was more of an exasperated "not another, here or there catch-22 discussion" -- so anyhow.

Anyhow, we don't need to vote on whether I can create a commons project for this. Probably what I envision happening is me going over there getting rejected because it should be here and here rejected bacause it should be there.

So we're voting on "create scratchpad target for lucene in the lucene repository" -- if not then I'll go get rejected on Commons because it should be here. (Catch-22)

-Andy

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


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

I 100% agree with you an minimizing beauracracy.

I think that we have been doing lots of talking and trying to handle issue,
but we haven't gone into action and made a decision. Since this is a
community process, I think the one way to do this is by providing areas
where people can express there ideas (i.e. Scratchpad) and voting when it
comes time to make a decision (like creating a more formal release process).

That's what I am trying to do with these initiatives. I don't think voting
takes very long.


> Finally, let me just add this, I'll make it short.
> I'm +1 for minimizing beaurocracy :)
> When people have constructive ideas, time, energy, and desire to
> contribute I'm all for supporting that. Not blindly, but not slowing
> them down too much. These things come in limited quantities,
> unfortunately :(

By the way here is the decision making rules for Jakarta, I was assuming a
consensus vote.

An action requiring consensus approval must receive at least 3 binding +1
votes and no binding vetos.
An action requiring majority approval must receive at least 3 binding +1
votes and more +1 votes than -1 votes.
All other action items are considered to have lazy approval until somebody
votes -1, after which point they are decided by either consensus or majority
vote, depending on the type of action item.

--Peter


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

Hi Otis,

The action item request is to create a scratchpad area in Lucene's CVS.


The scratchpad code would be part of the Lucene distribution nor part of the
build process. I should have made that more clear in my proposal.


If people are willing to create this an contribute there wares here, I think
this is a much better idea than in the commons area. I think that all the
Lucene related code should be part of the Lucene project. I don't even think
that there would be a link to it from the Lucene web page.

Which way are you going to vote?

--Peter




On 3/26/02 8:00 AM, "Otis Gospodnetic" <otis_gospodnetic@yahoo.com> wrote:

> Before we can really vote I think we need to have a common approach to
> this. One idea proposed by Andrew was Jakarta Common 'luceneappext'
> (long word, how about just LuceneApps?) subproject. This would mean
> org.apache.commons.luceneappext.
> On the other had Andrew said that he thinks of scratchpad as only
> another build target, so that implies keeping this under Lucene's
> Jakarta project.
> What you are suggesting is keeping it all within Lucene repository,
> etc.
> So which one is it? :)
>
> I think it may be easier to go with Jakarta Commons Sandbox, but I
> think the purpose of that Sandbox is that when code matures it migrates
> to Commons proper, and not elsewhere (not to Lucene). I could be
> wrong, maybe there are examples/subprojects that can easily show that
> I'm wrong :). In that case I'd vote for Jakarta Commons Sandbox
> approach, as I feel that it will be more clear that this is
> experimental/work-in-progress code.


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

+1 on creating a scratch area in Lucene's CVS that has build targets but is
not included in distributions.

I will write up and mail a description of the release process. This will
just be the mechanical steps involved (tag the repository, ant -D ..., scp
..., etc.) and not describe a policy.

Doug

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

> The scratchpad code would be part of the Lucene distribution nor part of the
> build process. I should have made that more clear in my proposal.
>
>
> If people are willing to create this an contribute there wares here, I think
> this is a much better idea than in the commons area. I think that all the
> Lucene related code should be part of the Lucene project. I don't even think
> that there would be a link to it from the Lucene web page.

Umm..probably would be a link. (see existing "plan" on the web page) --

Anyhow +1 on that.

> Which way are you going to vote?
>
> --Peter




On 3/26/02 8:00 AM, "Otis Gospodnetic" <otis_gospodnetic@yahoo.com> wrote:

> Before we can really vote I think we need to have a common approach to
> this. One idea proposed by Andrew was Jakarta Common 'luceneappext'
> (long word, how about just LuceneApps?) subproject. This would mean
> org.apache.commons.luceneappext.
> On the other had Andrew said that he thinks of scratchpad as only
> another build target, so that implies keeping this under Lucene's
> Jakarta project.
> What you are suggesting is keeping it all within Lucene repository,
> etc.
> So which one is it? :)
>
> I think it may be easier to go with Jakarta Commons Sandbox, but I
> think the purpose of that Sandbox is that when code matures it migrates
> to Commons proper, and not elsewhere (not to Lucene). I could be
> wrong, maybe there are examples/subprojects that can easily show that
> I'm wrong :). In that case I'd vote for Jakarta Commons Sandbox
> approach, as I feel that it will be more clear that this is
> experimental/work-in-progress code.


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

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


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

> The action item request is to create a scratchpad area in Lucene's
> CVS.

OK.

> The scratchpad code would be part of the Lucene distribution nor part
> of the
> build process. I should have made that more clear in my proposal.

Aha. There would be a build target, but the code would never make it
in the dist, in effect limiting the access to the code only to those
who have access to CVS repository.

> If people are willing to create this an contribute there wares here,
> I think
> this is a much better idea than in the commons area. I think that all
> the
> Lucene related code should be part of the Lucene project. I don't
> even think
> that there would be a link to it from the Lucene web page.
>
> Which way are you going to vote?

In this case I would vote +1 for this, too.
And if it doesn't work out for some reason there is always cvs remove
-f...

I'm assuming you are keeping track of votes.
When/iff we get +3 and no -1s (or whatever the rules are), Andrew can
import whatever he has, etc.

Lets try to make a decision today.

Otis


> On 3/26/02 8:00 AM, "Otis Gospodnetic" <otis_gospodnetic@yahoo.com>
> wrote:
>
> > Before we can really vote I think we need to have a common approach
> to
> > this. One idea proposed by Andrew was Jakarta Common
> 'luceneappext'
> > (long word, how about just LuceneApps?) subproject. This would
> mean
> > org.apache.commons.luceneappext.
> > On the other had Andrew said that he thinks of scratchpad as only
> > another build target, so that implies keeping this under Lucene's
> > Jakarta project.
> > What you are suggesting is keeping it all within Lucene repository,
> > etc.
> > So which one is it? :)
> >
> > I think it may be easier to go with Jakarta Commons Sandbox, but I
> > think the purpose of that Sandbox is that when code matures it
> migrates
> > to Commons proper, and not elsewhere (not to Lucene). I could be
> > wrong, maybe there are examples/subprojects that can easily show
> that
> > I'm wrong :). In that case I'd vote for Jakarta Commons Sandbox
> > approach, as I feel that it will be more clear that this is
> > experimental/work-in-progress code.


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

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

> If people are willing to create this an contribute there wares here,
> I think
> this is a much better idea than in the commons area. I think that all
> the
> Lucene related code should be part of the Lucene project. I don't
> even think
> that there would be a link to it from the Lucene web page.
>
> Which way are you going to vote?

> In this case I would vote +1 for this, too.
> And if it doesn't work out for some reason there is always cvs remove
> -f...

> I'm assuming you are keeping track of votes.
> When/iff we get +3 and no -1s (or whatever the rules are), Andrew can
> import whatever he has, etc.

> Lets try to make a decision today.

> Otis

Thats me, doug, you - thats 3. If no one delivers a -1 then we're done.

-Andy


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


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

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

I prefer instead to have the /contrib area a separate CVS repo. My
experience in other OS projects is that (a) contrib areas rapidly get
to be larger than then main distribution, making downloads slower, and
(b) often get out of sync with the main distribution. The result is
that a mix of core code and contributions of varying levels of
quality, completedness, and maintainedness tends to lower the perceived
level of quality of the distribution.

So +1 for a /contrib area, -1 for making it part of the main CVS repo
and distribution.

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

Again, -1 if this is part of the main CVS repo, +1 on the concept.

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

+1

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

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.
>
+1.
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: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

Hi Brian,

I have a suggestions that would be a little different, but I think would
accomplish the same function. I was looking at the current Jakarta CVS
repositories and it looks like we might create a sublevel under
Jakarta-lucene.

Right now the CVS repository looks like

/jakarta-lucene/docs
/jakarta-lucene/xdocs
/jakarta-lucene/src
/jakarta-lucene/lib
...


What about
/jakarta-lucene/contrib/docs
/jakarta-lucene/contrib/xdocs
/jakarta-lucene/contrib/src
/jakarta-lucene/lib
/jakarta-lucene/scratchpad/docs
/jakarta-lucene/scratchpad/xdocs
/jakarta-lucene/scratchpad/src
/jakarta-lucene/lucene/docs
/jakarta-lucene/lucene/xdocs
/jakarta-lucene/lucene/src
...


This way if you wanted to just cvs to get the core lucene build you can
point to /jarkarta-lucene/lucene/... Instead of jarkarta-lucene/...

Thoughts anyone

--Peter


------------------------------------------------------------------------


On 3/26/02 11:00 AM, "Brian Goetz" <brian@quiotix.com> wrote:

>> 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.
>
> I prefer instead to have the /contrib area a separate CVS repo. My
> experience in other OS projects is that (a) contrib areas rapidly get
> to be larger than then main distribution, making downloads slower, and
> (b) often get out of sync with the main distribution. The result is
> that a mix of core code and contributions of varying levels of
> quality, completedness, and maintainedness tends to lower the perceived
> level of quality of the distribution.
>
> So +1 for a /contrib area, -1 for making it part of the main CVS repo
> and distribution.
>
>> 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).
>
> Again, -1 if this is part of the main CVS repo, +1 on the concept.
>
>> 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).
>
> +1
>
> --
> 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>

Peter Carlson wrote:

>Hi Brian,
>
>I have a suggestions that would be a little different, but I think would
>accomplish the same function. I was looking at the current Jakarta CVS
>repositories and it looks like we might create a sublevel under
>Jakarta-lucene.
>
>Right now the CVS repository looks like
>
>/jakarta-lucene/docs
>/jakarta-lucene/xdocs
>/jakarta-lucene/src
>/jakarta-lucene/lib
>...
>
>
>What about
>/jakarta-lucene/contrib/docs
>/jakarta-lucene/contrib/xdocs
>/jakarta-lucene/contrib/src
>/jakarta-lucene/lib
>/jakarta-lucene/scratchpad/docs
>/jakarta-lucene/scratchpad/xdocs
>/jakarta-lucene/scratchpad/src
>/jakarta-lucene/lucene/docs
>/jakarta-lucene/lucene/xdocs
>/jakarta-lucene/lucene/src
>...
>
>
>This way if you wanted to just cvs to get the core lucene build you can
>point to /jarkarta-lucene/lucene/... Instead of jarkarta-lucene/...
>
Sounds good. Maybe /jakarta-lucene/core or main instead? But either way,
I like it. +1.

>
>
>Thoughts anyone
>
>--Peter
>
>
>------------------------------------------------------------------------
>
>
>On 3/26/02 11:00 AM, "Brian Goetz" <brian@quiotix.com> wrote:
>
>>>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.
>>>
>>I prefer instead to have the /contrib area a separate CVS repo. My
>>experience in other OS projects is that (a) contrib areas rapidly get
>>to be larger than then main distribution, making downloads slower, and
>>(b) often get out of sync with the main distribution. The result is
>>that a mix of core code and contributions of varying levels of
>>quality, completedness, and maintainedness tends to lower the perceived
>>level of quality of the distribution.
>>
>>So +1 for a /contrib area, -1 for making it part of the main CVS repo
>>and distribution.
>>
>>>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).
>>>
>>Again, -1 if this is part of the main CVS repo, +1 on the concept.
>>
>>>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).
>>>
>>+1
>>
>>--
>>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>
>
>




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

I took that for granted.

On Tue, 2002-03-26 at 17:08, Peter Carlson wrote:
> Hi Brian,
>
> I have a suggestions that would be a little different, but I think would
> accomplish the same function. I was looking at the current Jakarta CVS
> repositories and it looks like we might create a sublevel under
> Jakarta-lucene.
>
> Right now the CVS repository looks like
>
> /jakarta-lucene/docs
> /jakarta-lucene/xdocs
> /jakarta-lucene/src
> /jakarta-lucene/lib
> ...
>
>
> What about
> /jakarta-lucene/contrib/docs
> /jakarta-lucene/contrib/xdocs
> /jakarta-lucene/contrib/src
> /jakarta-lucene/lib
> /jakarta-lucene/scratchpad/docs
> /jakarta-lucene/scratchpad/xdocs
> /jakarta-lucene/scratchpad/src
> /jakarta-lucene/lucene/docs
> /jakarta-lucene/lucene/xdocs
> /jakarta-lucene/lucene/src
> ...
>
>
> This way if you wanted to just cvs to get the core lucene build you can
> point to /jarkarta-lucene/lucene/... Instead of jarkarta-lucene/...
>
> Thoughts anyone
>
> --Peter
>
>
> ------------------------------------------------------------------------
>
>
> On 3/26/02 11:00 AM, "Brian Goetz" <brian@quiotix.com> wrote:
>
> >> 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.
> >
> > I prefer instead to have the /contrib area a separate CVS repo. My
> > experience in other OS projects is that (a) contrib areas rapidly get
> > to be larger than then main distribution, making downloads slower, and
> > (b) often get out of sync with the main distribution. The result is
> > that a mix of core code and contributions of varying levels of
> > quality, completedness, and maintainedness tends to lower the perceived
> > level of quality of the distribution.
> >
> > So +1 for a /contrib area, -1 for making it part of the main CVS repo
> > and distribution.
> >
> >> 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).
> >
> > Again, -1 if this is part of the main CVS repo, +1 on the concept.
> >
> >> 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).
> >
> > +1
> >
> > --
> > 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>
>
--
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>

Brian,

> > > I prefer instead to have the /contrib area a separate CVS repo.
> My
> > > experience in other OS projects is that (a) contrib areas rapidly
> get
> > > to be larger than then main distribution, making downloads
> slower, and
> > > (b) often get out of sync with the main distribution. The result
> is
> > > that a mix of core code and contributions of varying levels of
> > > quality, completedness, and maintainedness tends to lower the
> perceived
> > > level of quality of the distribution.
> > >
> > > So +1 for a /contrib area, -1 for making it part of the main CVS
> repo
> > > and distribution.

Even if the contents of /contrib are compressed archives (e.g. .zip or
.tgz or ...)? That way the sync question is not a problem - we just
provide the packages, we do not try to repackage them.
Also, they would not be a part of the distribution that users get,
would they Peter? They would be available separately, somehow (perhaps
via links from the Contributions page pointing straight to the CVS
repository's /contrib section).
With that in mind, again if I'm not misinterpreting things, would you
still vote against 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).
> > >
> > > Again, -1 if this is part of the main CVS repo, +1 on the
> concept.

It sounds like you are saying the arguments for this -1 are the same as
for the above (size and sync issue).
My understanding is that stuff in scratchpad would not really be trying
to remain in sync with outside code. Isn't that so, Andrew?
And as for size, this would not be a pile of code, plus it would not be
in the Lucene distribution, so you would only see it if you are
updating your CVS repository. No?

Do you still give this -1?
If so, could you please provide some alternative ideas?

Thanks,
Otis


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

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

> It sounds like you are saying the arguments for this -1 are the same as
> for the above (size and sync issue).
> My understanding is that stuff in scratchpad would not really be trying
> to remain in sync with outside code. Isn't that so, Andrew?

No thats not true. And generally most projects go so far as to cause
the build to break if scratchpad won't build "because they'll have to
work together eventually anyway"

> And as for size, this would not be a pile of code, plus it would not be
> in the Lucene distribution, so you would only see it if you are
> updating your CVS repository. No?
>
> Do you still give this -1?
> If so, could you please provide some alternative ideas?
>

Um the onus to come up with alternatives is on you:

http://jakarta.apache.org/site/decisions.html (see alternative under
long term plans)

Basically its this or I just go try and create a project in commons
(which no offense, I don't have to have anyone here's approval to do
that so I'd rather save my breath for commons if we're going there).
There are many downsides to this for one we'll not have the benefit of
feedback from the general project (it shall just be dropped in your lap
at the end). The common's mail list is a zoo so it will be hard to
follow. (its time to split it but they don't know it yet).

I'm a bit dismayed by one thing. You've not looked at the way its
implemented in the projects I've pointed out. It might address some of
your concerns:

jakarta.apache.org/poi
xml.apache.org/cocoon

For this effort the goal is to get this refactored QUICKLY so it can
join the project without making a mess of CVS as things get refactored.

-Andy


> Thanks,
> Otis
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards®
> http://movies.yahoo.com/
>
> --
> 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>

Hello,

--- "Andrew C. Oliver" <acoliver@apache.org> wrote:
>
> > It sounds like you are saying the arguments for this -1 are the
> same as
> > for the above (size and sync issue).
> > My understanding is that stuff in scratchpad would not really be
> trying
> > to remain in sync with outside code. Isn't that so, Andrew?
>
> No thats not true. And generally most projects go so far as to cause
> the build to break if scratchpad won't build "because they'll have to
> work together eventually anyway"

I wasn't clear enough. When I said 'outside code' I meant the code
that was contributed that you want to refactor. I wasn't referring to
the Lucene code. It definitely needs to be in sync with the latter if
you want to be able to even compile it. Do you intend to keep it in
sync with the original author's code updates?

> > And as for size, this would not be a pile of code, plus it would
> not be
> > in the Lucene distribution, so you would only see it if you are
> > updating your CVS repository. No?
> >
> > Do you still give this -1?
> > If so, could you please provide some alternative ideas?
> >
>
> Um the onus to come up with alternatives is on you:

I think you are mistaking me for Brian here.

> http://jakarta.apache.org/site/decisions.html (see alternative under
> long term plans)

No voting required? Works for me in this situation, if that is the
fair thing to do.

> Basically its this or I just go try and create a project in commons
> (which no offense, I don't have to have anyone here's approval to do
> that so I'd rather save my breath for commons if we're going there).
> There are many downsides to this for one we'll not have the benefit
> of
> feedback from the general project (it shall just be dropped in your
> lap
> at the end). The common's mail list is a zoo so it will be hard to
> follow. (its time to split it but they don't know it yet).

I agree with the above.

> I'm a bit dismayed by one thing. You've not looked at the way its
> implemented in the projects I've pointed out. It might address some
> of
> your concerns:
>
> jakarta.apache.org/poi
> xml.apache.org/cocoon
>
> For this effort the goal is to get this refactored QUICKLY so it can
> join the project without making a mess of CVS as things get
> refactored.

Hey, I'm pro suggested changes! :)

Otis


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

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