> Hm, again I'm confused. If this is how it worked in Solr/Lucene > land, then there wouldn't be pieces in Solr that we now want to > refactor and move into Lucene core or modules. A list of about 4-5 > such pieces of functionality in Solr has already been listed. > That's really my main question. Why were/can't things be committed > to the appropriate place? Why where they committed to Solr?
Pre-merge: If someone wants a new functionality in Solr they should be free to create a patch to make it work well, in Solr, alone. To expect them to also factor it so that it works well for Lucene-only users is wrong. They should not need to, nor be expected to, and they shouldn't feel bad not having factored it that way. They use Solr and they need it working in Solr and that was their itch and they scratched it and net/net that was a great step forward for Solr. We should not up and reject contributions because they are not well factored for the two projects. Beggars can't be choosers... Someone who later has the itch for this functionality in Lucene should then be fully free to pick it up, refactor, and make it work in Lucene alone, by poaching it (pulling it into Lucene). Poaching is a natural way for code to be pulled across projects... and while in the short term it'd result in code dup, in the long term this is how refactoring can happen across projects. It's completely normal and fine, in my opinion. But poaching, while effective, is slow ... Lucene would poach, have to stabilize & do a release, Solr would have to upgrade and then fix to cutover to Lucene's sources (assuming the sources hadn't diverged too much, else Solr would have to wait for Lucene's next release, etc.) And we have *alot* of modules to refactor here, between Solr and Lucene. So for these two reasons I vote for merging Solr/Lucene dev over gobbs of poaching. That gives us complete freedom to quickly move the code around. Poaching should still be perfectly fine for other cases, like pulling analyzers from Nutch, from other projects, etc. Mike
