On Thu, Mar 4, 2010 at 2:40 PM, Michael McCandless <luc...@mikemccandless.com> wrote: > On Thu, Mar 4, 2010 at 5:51 AM, Uwe Schindler <u...@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
