lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: Action Item Vote Request
Date Tue, 26 Mar 2002 16:00:27 GMT
> 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>


Mime
View raw message