lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 16:19:47 GMT
If we vote on what Mike says, I revise my vote and simply vote +/-0 to not stop progress. I
have some problem with the construct but in general I am fine with merging dev lists, splitting
into modules, merged committers - but not the requirement on tests pass always. In my opinion,
if anything changed in lucene breaks some tests we could open an issue in solr.

One idea: If we really make solr depend on the new lucene lib, solr should not have lucene
jars in its lib folder, but instead the nightly build should fetch the jars from the lucene
hudson build. For committers working in svn, maybe some relation to rev numbers (like we do
for lucene backwards tests) can be put into solrs common-build.xml so the ant script of solr
can checkout the correct lucene rev and build it on they fly.


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

View raw message