lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 15:46:04 GMT
I think many of the objections I've seen so far come from the fact that people don't really
know what Solr is.  Solr is much more than simply a "server" around Lucene.

Look at the other thread.  Here's a minimal list of things that a very large chunk of people
who writes a Lucene app for production has to do:

1. Analyzers
2. Functions
3. Schema (although likely abstracted/reworked)
4. Warming/Reopen - this is hard code to get right and I've seen many people do it wrong.
 It is also yet another area of duplication where something started in Solr b/c for years
the Lucene community had no interest in donating code for it (incRef/decRef)
5. Faceting

If someone came in and contributed all of those things to Lucene, there would be no objection.
 Simply the fact that Solr has other things around it doesn't mean people have to use them
and no one is proposing some Uber JAR.


On Mar 9, 2010, at 10:13 AM, Mattmann, Chris A (388J) wrote:

> Hi Yonik,
> 
>>> I have built 10s of projects that
>>> have simply used Lucene as an API and had no need for Solr, and I've built
>>> 10s of projects where Solr made perfect sense. So, I appreciate their
>>> separation.
>> 
>> As does everyone - which is why there will always be separate
>> downloads.  As a user, the only side affect you should see is an
>> improved Lucene and Solr.
> 
> Developers make downloads. Software processes guide developers who are
> producing those downloads. Policies guide the direction of a project. They
> are intimately intertwined.
> 
>> 
>> Saying that Solr should move some stuff to Lucene for Lucene's
>> benefit, without regard to if it's actually benefitial to Solr, is a
>> non-starter.  
> 
> I'm not sure it's Solr's decision what the Lucene committers decide to move
> to Lucene, neither is it Lucene's decision in the opposite direction. These
> are all Apache projects, subprojects of the Lucene TLP. I'm not sure what
> the debate is? If Solr wants elements from Lucene that aren't part of Solr
> yet b/c Solr is relying on an old version of Lucene:
> 
> 1. upgrade to Lucene trunk and address the issues it brings in Solr
> 2. duplicate the Lucene code in Solr, address any issues there, and then
> contribute it back
> 
> I'd recommend the same to any project, regardless of what TLP it resides in,
> and in many cases, where it's at the ASF, or Sourceforge, or wherever.
> 
> It seems kind of incestuous and an abuse of power to make the case that
> "well because we're all committers on both projects, then this..." I keep
> hearing a lot of talk about "hats", which in analogy means that though you
> are one person you have different concerns/projects/etc. This is another
> example of the need to maintain separate hats.
> 
> Cheers,
> Chris
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 

--------------------------
Grant Ingersoll
http://www.lucidimagination.com/

Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search


Mime
View raw message