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 properties. > > 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. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
