lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <simon.willna...@googlemail.com>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 14:21:29 GMT
On Thu, Mar 4, 2010 at 2:40 PM, Michael McCandless
<lucene@mikemccandless.com> wrote:
> On Thu, Mar 4, 2010 at 5:51 AM, Uwe Schindler <uwe@thetaphi.de> 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

I don't know why this is such a big problem except of the consumed
time by running the tests of both. Yet, for a lucene committer it
takes about 5-8 min to run all the test, no idea how long solr tests
take. Aside of this it would give me a way better feeling to commit
changes if all those test pass. BWCompat policy will force you to not
break stuff in a large scale and the solr tests are a good judge for
that!
>
>  * Release both at once (but the specific logistics is still up for
>   discussion)
>
>  * 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,
>   queries)
That is one of the things I would love to see. I worked with lucene on
mobile devices and each 1kb is valuable if you just need a small
subset of lucene. The core should be as small as possible IMO.
>
> 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.
>
> OK
>
>> 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.
Absolutely true!
>
>> 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.
>
> Right.
I agree but with solr we will have a whole bunch of guys who will be able too
>
>> 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
> times.
>
> 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
> issue.
>
> Mike
>

Are we still voting or is this already a discussion?
If we are voting, +1 from me!


Simon

Mime
View raw message