lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 15:42:11 GMT
Hi Robert,

>> 2. duplicate the Lucene code in Solr, address any issues there, and then
>> contribute it back
> Not that I can stop anything, but -1 to any further analysis code
> duplication. There has to be a better way.

There might be, but as a first start, duplication is a quick way to get
going and experiment. As solutions that evolve over time are matured, the
time can come for integration. Parallel tracks allows projects to move
forward operationally, and enforces insulation, loose coupling and other

> Its stupid to duplicate the code. Its also stupid to just move the code.

I'm not sure anything is "stupid" per-se. There are different approaches
which address different concerns.

> In my opinion, if Solr has an analysis feature that belongs in lucene,
> we want not just the code, but improvements, ideas, comments from solr
> developers that have experience with it, we want to pay
> attention to open Solr JIRA tickets against that feature, we want
> things like the Solr example schema to have good "defaults" for any
> potential improvements to it, and we want the wiki to reflect
> additional improvements it supports.

Then I think it's fair to say that those that want this can follow the
normal Apache process to do so:

* subscribe to the mailing lists
* post JIRA issues with patches
* get those patches committed
* become a committer, etc.


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message