lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Factor out a standalone, shared analysis package for Nutch/Solr/Lucene?
Date Mon, 01 Mar 2010 19:00:19 GMT

: I've started to think that a merge of Solr and Lucene would be in the
: best interest of both projects.

As I already mentioned in my previous reply: I think there are incremental 
steps that could be made before we spend too much effort worrying if/how 
Solr develpment could be more tightly integrated with Lucene-Java 
development; or if Solr should be a TLP.

But this is a different message, where I reply to the larger issue from a 
slightly differnet perspective just in case I get hit by a bus and don't 
get a chance to bring it up if/when the conversation wrrants it.

It woulr probably be wise to consider the overall issues from an 
anthropological standpoint -- by looking at other (ASF) projects that have 
been in similar situations.

On the one hand: "branching" projects so that sub project graduates from 
project and become their own TLPs seems to generally be the norm -- so 
maybe we should ask the (obvious) question of why? ... not all existing 
TLPs make good corrolaries, but (based on my limited understanding) it 
might make sense to look at something like "HTTPD vs APR" in particulr:  
HTTPD came first, and APR was refactored out of it -- but except for the 
ordering a similar relationship could be found between Solr and 
Lucene-Java (one is a server, the other is the core foundation on which 
it's built) ... so why did APR spin off into it's own TLP instead of just 
being a product developed/released in lock step with HTTPD?

Conversly: Hadoop has lots of subprojects with divergent user 
communities, but (again: based on my limited understanding) they 
have moved towards doing development with some tight coupling in their 
release / compatibility processes. (ie: consistent version numbers between 
products based on the hadoop-core they use) ... how well does that work 
out for them?  what issues do they face?

Better understanding those situations could help us avoid making 
costly mistakes.


View raw message