lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DM Smith" <dmsmith...@gmail.com>
Subject Re: Core vs Contrib
Date Wed, 21 Jun 2006 17:25:15 GMT
Otis,
I should have taken a closer look before I made my comment. I have just now.
So never mind.
DM

On 6/21/06, Otis Gospodnetic <otis_gospodnetic@yahoo.com> wrote:
>
> Chris,
>
> Judging from a cursory look at LUCENE-406, that should be in the core (my
> reasoning was: well, if it's simply the direct opposite of what's already in
> the core, it makes sense to sit right next to its opposite in the core with
> the "opposite name", or else who'll think to look in contrib, especially
> contrib/misc).
>
> We currently have only 2 places for code - core and contrib.  Where new
> stuff should go can be discussed, but I think it's almost always very
> obvious.
>
> I think of this as:
> code/fundamental - what all programs use by using the Lucene API
> contrib/useful - what many programs might use - current contrib
>
> I think "mostly examples and code that is not quite ready to be classed as
> useful"-type code typically doesn't get committed.  Sometimes it sits in
> JIRA and rots, but typically if code is not useful people don't contribute
> it, or at least that's what I've observed.
>
> Otis
>
> ----- Original Message ----
> From: Chris Hostetter <hossman_lucene@fucit.org>
> To: Lucene Dev <java-dev@lucene.apache.org>
> Sent: Wednesday, June 21, 2006 3:43:23 AM
> Subject: Re: Core vs Contrib
>
>
> : I think that it might be good to define 3 levels:
> : fundamental - what all programs probably will use
> : useful - what many programs might use
> : contrib - mostly examples and code that is not quite ready to be
> : classed as useful
>
> Those three levels make sense -- but they don't map to what's currently
> available in the Subversion repository.  Unless I create a new
> "useful" directory and make the neccessary changes to the build system to
> build everything in it, my current choices are to put new features in
> contrib, or add them to the core.
>
> : On Jun 16, 2006, at 6:03 PM, Chris Hostetter wrote:
>
> : > Are there any written (or unwritten) guidelines on when something
> : > should
> : > be commited to the core code base vs when a contrib module should
> : > be used?
> : >
> : > Obviously if a new feature rquires changing APIs omodifying one of the
> : > existing core classes, then that kind of needs to be in the core --
> : > and
> : > there is precidence for the idea thatlangauge specific analyzers
> : > should go
> : > in contrib; and then of course there are things like the Span queries
> : > which seem like htey would have been a prime canidate for a contrib
> : > module
> : > but they aren't (possibly just because when they were added there
> : > was no
> : > "contrib" -- just the sandbox, and it didn't rev with lucene core).
> : >
> : > ...But I'm just wondering if as we move forward, there should be some
> : > sated policy "unless there is a specific reason why it must be in the
> : > core, put it in a contrib" to help keep the core small -- or if i'm
> : > wrong
> : > about hte general sentiment of the Lucene core.
> : >
> : >
> : > (FYI: my impedus for asking this question is LUCENE-406 -- I think
> : > it's a
> : > pretty handy feature that everyone might want, but that doesn't
> : > mean it's
> : > not just as usefull commited in contrib/miscellaneous)
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message