lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Sun, 14 Mar 2010 19:58:39 GMT

----- Original Message ----
> From: Yonik Seeley <>
> To:
> Sent: Sun, March 14, 2010 3:48:10 PM
> Subject: Re: [VOTE] merge lucene/solr development (take 3)
> On Sun, Mar 14, 2010 at 2:36 PM, Otis Gospodnetic
> ymailto="" 
> href="">> 
> wrote:
>  if I understand things correctly, poaching is only needed 
> when the code is not committed in the
> "right" project/location to begin 
> with.

That is the problem though - Solr should be allowed to keep 
> whatever
code was written under it's control, w/o pressure to put it in 
> Lucene

But don't we want DRY?
And don't we want to take some of the goodness that evolved under Solr and modularize it,
so that vanilla-Lucene users can benefit from individual pieces?

> (and often out of reach).

Does this remain true if we get Lucene trunk jar -> Solr trunk lib going on a regular (e.g.
nightly) basis?

> And Lucene should be able to poach 
> what it wants from Solr.  But with the projects already half 
> overlapping... it was a recipe for conflict.

Poaching - right, it's just that if you build X in project A and then you want to move X to
project B, it seems like more work needs to be done than if X was committed to B to begin

> We've already had 
> conflicts about this in the past.  The conflicts were either going to 
> get worse over time, esp with Solr not on Lucene's trunk, or we were going to 
> merge.  We've decided to tear down the artificial wall and work 
> together.

> Some people suggest that this could have worked w/o 
> merging.  I disagreed, as I think the majority of those voting +1 
> disagreed.

> Not sure who's following lucene-dev and solr-dev, but the 
> committers have already been merged. We're not standing 
> still...

So there was talk of Lucene core and the new idea of Lucene modules, which are really just
standalone libs/APIs/jars, right?
Would it make sense to think of Solr as one such Lucene module?
In other words, don't even bother with merging just the -dev lists, but really just merge
everything.  In that case Solr's relationship with Lucene core becomes much like the relationship
Lucene contribs have with Lucene core today in terms of compatibility, builds, and committers'

That kind of makes sense to me.  Of course, because of the sheer volume we may want to keep
-user lists separate and possibly even create new ones for Lucene modules that attract enough
interest on their own.


View raw message