lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 13:40:00 GMT
On Thu, Mar 4, 2010 at 5:51 AM, Uwe Schindler <> wrote:

>> > - And last but not least the whole merge should be done *after* the
>> >   current code bases are again closer to each other, especially Flex
>> >   is in and Solr is at least on Lucene 3.0.1.
>> Well, this really is a logistical question (ie not really a reason for
>> casting a -1 vote).
> The -1 was for the vote in general as it is not clear about what we
> are voting.

We are voting on this:

 * Merging the dev lists into a single list.

 * Merging committers.

 * When any change is committed (to a module that "belongs to" Solr or
   to Lucene), all tests must pass

 * Release both at once (but the specific logistics is still up for

 * Modularlize the sources: pull things out of Lucene's core (break
   out query parser, move all core queries & analyzers under their
   contrib counterparts), pull things out of Solr's core (analyzers,

These things would not change:

 * Besides modularizing (above), the source code would remain factored
   into separate dirs/modules the way it is now.

 * Issue tracking remains separate (SOLR-XXX and LUCENE-XXX issues)

 * User's lists remain separate.

 * Web sites remain separate.

 * Release artifacts/jars remain separate

> I am fine with fixing bugs in solr that are there before the change
> but only appear because of the change.


> My problem is more such things like the per-segment-mega-problem
> because Solr was simply using Lucene incorrectly (I hope this is
> said too hard).

You know, Lucene also used those APIs "incorrectly" until we cutover
Lucene's search to be per-segment ;)  We "got lucky" in that the APIs
were at best "ambiguous" about whether the incoming reader was
per-segment or not.

> We did not break backwards.

Right, and so Solr's tests should have passed.

> But if we would had to repair the whole solr (which is still not
> finished) after the per-segment change, we were still not having
> per-segment search.

But you won't have to fix Solr from such a change.  Others (people
wearing Solr hats) will.

> And fixing this is surely not easy possible for non-solrcore
> developers like me or you.


> So even if development goes together we should still have the
> possibility to update lucene and if its not a backwards break but
> incorrect usage of Lucene's API (or assumptions on behavior of
> Lucene's API that are not documented or are obvious from API design
> - like for Filters have never to work on Top-Level Searchers and
> *only* use the passed in IndexReader), I would simply break solr and
> let the solr devs fix it in a separate issue.

There would no longer be solr devs -- just "devs" who sometimes wear
Solr hats, sometimes wear Lucene hats, sometimes both, at different

Uwe, this is in fact the proposal -- you can break Solr (but you must
pass its tests), and devs with Solr hats will fix it.  It's a separate


View raw message