lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: Less drastic ways
Date Sun, 14 Mar 2010 19:50:47 GMT
Hello,

----- Original Message ----
> From: Grant Ingersoll <gsingers@apache.org>
> To: general@lucene.apache.org
> Sent: Sun, March 14, 2010 12:40:51 PM
> Subject: Re: Less drastic ways
> 
> 
On Mar 14, 2010, at 12:28 PM, Otis Gospodnetic wrote:

> 
> Hi,
> 
> Consider this just an email to clarify things for Otis (and 
> maybe a few other people).
> 
> Are the following the main goals of 
> the recent merge voting thread(s)?
> * Make it easier for Solr to ride the 
> Lucene trunk
> * Make it easier for people to avoid committing new 
> features to Solr when they really belong to some lower level code - either 
> Lucene core or some Lucene module
> 
> Is the only or main change 
> being proposed that lucene-dev and solr-dev mode to some common-dev (or 
> lucene-dev)?
> 
> If the above is correct, here is what I don't 
> understand:
> * Why can't Solr riding on Lucene trunk be achieved by 
> getting Lucene trunk build into Solr lib in svn on a daily/hourly 
> basis?

GI: I just don't see that working.


OG: Could you please elaborate?  Also, why not try it and see?  It requires very little infrastructure
changes and no reorg.  Reorg can always be done later if this first step proves to be inadequate.

> * Why can't existing 
> Solr functionality that has been identified as "should really have been 
> committed to Lucene instead of Solr" be moved to Lucene over the coming 
> months?

GI: First up is analysis, I suspect.


OG: Si!

> * Why can't Solr 
> developers be required to be subscribed to lucene-dev?

They should.  
> That's the immediate step going forward until the various infra gyrations are 
> undertaken.

> * Why can't Solr developers be required/urged to commit 
> any new functionality to Lucene if solr-dev and lucene-dev people think that's 
> where it belongs? i.e. communicate before committing - the same as "measure 
> twice, cut once".

GI: Of course they will.  This is how committing works on any and all projects anyway.


OG: Hm, again I'm confused.  If this is how it worked in Solr/Lucene land, then there wouldn't
be pieces in Solr that we now want to refactor and move into Lucene core or modules.  A list
of about 4-5 such pieces of functionality in Solr has already been listed.  That's really
my main question.  Why were/can't things be committed to the appropriate place?  Why where
they committed to Solr?

Thanks,
Otis


Mime
View raw message