lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrzej Bialecki>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 11:09:29 GMT
On 2010-03-09 11:40, Michael McCandless wrote:
> On Tue, Mar 9, 2010 at 5:10 AM, Andrzej Bialecki<>  wrote:
>> Re: Nutch components - those that are reusable in Lucene or Solr
>> contexts eventually find their way to respective projects, witness
>> e.g. CommonGrams.
> In fact I think this is a great example -- as far as I can tell,
> CommonGrams was poached from Nutch, into Solr, and then was
> nurtured/improved in both projects separately right?

Right. In fact, Nutch would like to eventually delegate indexing solely 
to Solr, at which point we will reuse the CommonGrams from Solr.

> So.... can/should we freely poach across all our sub projects?

In my opinion: with proper attribution, by all means!

> It has obvious downsides (it's essentially a fork that will confuse
> those users that use both Solr&  Lucene, in the short term, until
> things "stabilize" into a clean refactoring; it's double the dev; we
> must re-sync with time; etc.).
> But it has a massive upside: it means we don't rely only on "push"
> (Solr devs to push into Lucene or vice/versa).  We can also use "pull"
> (Lucene devs can pull pieces from Nutch/Solr into Lucene).  It becomes
> a 2-way street for "properly" factoring our shared code with time.
> If we had that freedom ("poaching is perfectly fine"), then,
> interested devs could freely "refactor" across sub projects.
> Not having this freedom today, and not having merged dev, is stunting
> both Solr&  Lucene's growth.

Erhm.. don't we have this freedom already??? Another example is 
TimeLimitedCollector - poaching _is_ perfectly fine as far as I'm 
concerned. All projects are under the same license, often also share the 
same people, so I see no reason not to share freely where it makes sense 
from technical POV, though we may sometimes succumb to the NIH syndrome ;)

This push/pull between the projects reminds me of discussions with my 
clients when I try to convince them to open-source some generic 
functionality: long-term you can only benefit greatly from getting rid 
of generic code, if there's a lively community with focus just on that 
functionality - you don't have to maintain it and you reap the benefits 
of external development, and you can focus on developing of what's 
unique to your project.

So, I'm all for the poaching ;) but IMHO this doesn't necessitate the 
merge, just refactoring, push/pull and the right mindset.
Best regards,
Andrzej Bialecki     <><
  ___. ___ ___ ___ _ _   __________________________________
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration  Contact: info at sigram dot com

View raw message