lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Less drastic ways
Date Sun, 14 Mar 2010 20:34:42 GMT
> 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?


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

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

Poaching should still be perfectly fine for other cases, like pulling
analyzers from Nutch, from other projects, etc.


View raw message