Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4B96704D.5020501@apache.org>
Date: Tue, 09 Mar 2010 09:59:09 -0600
From: Dennis Kubes <kubes@apache.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: general@lucene.apache.org
Subject: Re: [VOTE] merge lucene/solr development (take 3)
References: <C7BBA59D.DD56%Chris.A.Mattmann@jpl.nasa.gov>
 <544AC1BC-7A1A-42E5-9CFC-57A60E972760@apache.org>
In-Reply-To: <544AC1BC-7A1A-42E5-9CFC-57A60E972760@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I agree.  Most of those things can/should be moved into Lucene.  That 
doesn't necessitate merging.  Separate responsibilities.

 > For that matter, why do we even need to have this discussion at all? 
  > Most of us Solr committers are Lucene committers.  We can simply start
 > committing Solr code to Lucene such that in 6 months the whole
 > discussion is moot and the three committers on Solr who aren't Lucene
 > committers can earn their Lucene merit very quickly by patching the
 > "Solr" portion of Lucene.  We can move all the code to it's
 > appropriate place, add a contrib module for the WAR stuff and the
 > response writers and voila, Solr is in Lucene, the dev mailing lists
 > have merged by the fact that Solr dev would be defunct and all of the
 > proposals in this vote are implemented simply by employing our commit
 > privileges in a concerted way.

Am I reading you right.  Are you are proposing a hostile takeover of the 
Lucene project?  Even being committers there needs to be discussion with 
the community about the best path.  Or are you suggesting we bypass 
discussion?  I am now even more concerned that merging is not the right 
way to go.

Dennis

Grant Ingersoll wrote:
> 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
>