: 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 iterative. -Hoss
