lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 21:03:36 GMT
----- Original Message ----

> From: Uwe Schindler <uwe@thetaphi.de>
> To: general@lucene.apache.org
> Sent: Thu, March 4, 2010 11:19:47 AM
> Subject: RE: [VOTE] merge lucene/solr development
> 
> 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.

I think that's what's being proposed.  With this proposal people wearing Solr dev hats will
know they need to fix Solr sooner than they know now - Hudson will tell them on a regular
basis, even if you don't spot the Solr test failing or even if you spot it, but don't enter
it into JIRA because you know Hudson will tell Solr guys something in Lucene trunk changed
very recenly and broke Solr.

Guys, is this interpretation correct?

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

I was wondering the same thing.  That way svn repos don't need to be reorganized.  Or maybe
there is some svn repo linking trickery that's possible.

Otis

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


Mime
View raw message