lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 10:51:04 GMT
> > - A modularization is needed: Lucene-Core (with no analyzers at all,
> >   only abstract classes), Lucene-Analysis, Lucene-Facetting,
> >   Lucene-FunctionQueries, Lucene-Foobar, Solr-Core, Solr-Foobar,...
> 
> I'm a huge fan of doing this as well, but, I see merging Solr/Lucene
> dev as a huge step towards making this modularization possible.
> 
> Maybe we can do this up front, when we merge?  EG moving concrete
> queries, analyzers out of core (keeping abstract base classes), moving
> queryParser out, seem like obvious first steps.  Hey then Lucene's JAR
> will be less than 1.0 MB again!

Yeah, QueryParser should go away from core (foget that).

> > - No requirement for Lucene Committers to work on Solr Tests or that
> >   Solr tests must pass when Lucene Changes. I would like to have it
> >   more in a way that the issue tracker would do that like it is now:
> >   Lucene is enhanced, BW layer still alive (so solr tests should
> >   work), so open issue against solr referring to lucene issue to fix
> >   solr and remove usage of deprecated methods or fix other problems.
> 
> First off, not breaking tests seems like a simple win?  Ie, if we're
> not breaking back compat, the tests all pass.  If we accidentally
> break back compat, the tests fail, and protect us, which is only good?
> 
> I think your real concern might be that you (and other "I want to
> focus only on core Lucene devs") might be forced to spend alot of time
> working on Solr when new changes happen in Lucene?

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). We did not break backwards.
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. 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.

> And take our work in flex -- if we're doing our jobs, landing flex will
> already pass all Solr tests.  I *really* want to have Solr tests
> confirm
> that we didn't break back-compat.  But I can't, now (Solr's not on
> trunk).

OK

> > - 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.

Uwe


Mime
View raw message