lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: Less drastic ways
Date Sun, 14 Mar 2010 21:29:42 GMT
I don't get it, Mike. :)
Even if we merge Lucene/Solr and we treat Solr as just another Lucene contrib/module, say,
contributors who care only about Solr will still patch against Solr and Lucene developers
or those people who have the itch for that functionality being in Lucene, too, will still
have to poach/refactor and pull that functionality in Lucene later on.  Whether Solr is a
separate project or a Lucene contrib/module that has its own user (and contributor) community
that is not tightly integrated with Lucene's -dev community, the same thing will happen, no?


Maybe it will help if we made things visual for us visual peeps.  Is this, roughly, what the
plan is:

trunk/
    lucene-core/
    modules/
        analysis/
        wordnet/
        spellchecker/
        whatever/
        ...
        facets/
        ...
        functions/
        solr/
            dih/
            ...

?

Thanks,
Otis ----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Hadoop ecosystem search :: http://search-hadoop.com/



----- Original Message ----
> From: Michael McCandless <lucene@mikemccandless.com>
> To: general@lucene.apache.org
> Sent: Sun, March 14, 2010 4:34:42 PM
> Subject: Re: Less drastic ways
> 
> > 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

Mime
View raw message