lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Q re merging dev MLs
Date Thu, 04 Mar 2010 23:35:17 GMT

: versions of HDFS.  So the direction there is the opposite of what's been
: proposed here: introducing layered project dependencies rather than reducing
: them. It's too soon to say how well that split will work, just as I think it's
: difficult to guess how well merging Lucene and Solr will fare.  From
: experience, we know the downsides of Lucene and Solr being split, now we may
: have the opportunity to learn the downsides of being merged!

I don't actually think we really have any clue about the 
benefits/downsides of being "split" .. as a sub-project some people seem 
to expect that Solr is in lock step with Lucene-Java, but if Solr became a 
TLP I think that impression would be reduced.

All of the same goals about wanting to have less duplicated code, and a 
build system that's more closely tied with the Lucene trunk would be just 
as possible if Solr were a TLP -- it's just a matter of modifying Solr's 
processes, refactoring/promoting existing code and encouraging Solr 
developers to contribute "common" code to Lucene-Java as well (and to get 
Solr committers to "reject" contributions that really belong in 
Lucene-Java) -- all of which just requires more effort on everyones part, 
but not neccessarily a change in process or project structure.  The 
increased effort is likely to be the same regardless of wether Solr is a 
subproject, or it's own TLP, or absorbed into Lucene-Java.


-Hoss


Mime
View raw message