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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
