On Thu, Mar 4, 2010 at 5:51 AM, Uwe Schindler <[email protected]> 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 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
