lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: [VOTE] merge lucene/solr development
Date Thu, 04 Mar 2010 18:45:10 GMT

: If Solr is not on Lucene trunk, that's not going to happen.
: Solr on Lucene trunk is key. Release cycles is key to that.
: Build process is key to getting devs that stick in one world to branch into
: the other just a bit.

Then approach the problem top down instead of bottom up: If this solr-dev
community is in general on board with the "merge" end goal, it shouldn't 
be hard to get a lot of solr commiters to work on modifying the Solr 
build process so it starts using Lucene trunk (or Lucene nightlies) and 
commiting hte changes to Solr to get that to compile/run properly -- if 
there are Lucene-Java changes neccessay to make that work, then those 
Solr-devs can submit patches back.

As you said in your last email "If they should be a commiter, they would 
contribute to the project and become one naturally" ... so why not just 
let nature take it's course?  If the Solr community moves it's build 
process to be tightly bound with the LUcene one *then* it can make sense 
to talk about lock step releases, and shared dev lists, etc...

I honestly don't care which direction we go, but we should be able do this 
incrementally -- if we can't, then we probably can't do it in one fell 
swoop either.

As I said: The whole thing feels like we're voting on a "goal" -- Goals 
are nice in that they give us an end point to aim for, but I can't 
remember any time we've ever voted on a "goal" ... this situation (saying 
"it would be really great to eventually be/have _____" so let's just set 
out to do that") doesn't feel like any change that's ever turned out well 
in Lucene.  

Things that have worked well in the past have been incremental and 


View raw message