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 14:48:15 GMT
Hey Grant,

On 3/9/10 5:49 AM, "Grant Ingersoll" <> wrote:

> For that matter, why do we even need to have this discussion at all?  Most of
> us Solr committers are Lucene committers.  We can simply start committing Solr
> code to Lucene such that in 6 months the whole discussion is moot and the
> three committers on Solr who aren't Lucene committers can earn their Lucene
> merit very quickly by patching the "Solr" portion of Lucene.

Sure, if folks agree on those patches and the community finds them useful,
and the patches follow the dev process of Lucene(-java), then so be it.
However, it seems like this could have been done already, no? Many of the
things you and others have discussed merging have been around for a while
besides spatial. Is it simply developers/resources that is lacking in
Lucene(-java) and time? Or are there other reasons? It sounds to me based on
the desire to sync up tests, to follow the same release schedule/etc., that
there are in fact, other reasons.

> We can move all 
> the code to it's appropriate place, add a contrib module for the WAR stuff and
> the response writers and voila, Solr is in Lucene, the dev mailing lists have
> merged by the fact that Solr dev would be defunct and all of the proposals in
> this vote are implemented simply by employing our commit privileges in a
> concerted way.  Yet, somehow, me thinks that isn't a good solution either,
> right?  Yet it is perfectly "legal" and is just as valid a solution as the
> "poaching" solution and in a lot of ways seems to be what Chris is proposing.

Whether or not what you're saying is good or what I'm saying is good or not
will be decided by the community within Lucene(-java), as well as the one
within Solr. All I'm for is not circumventing that process, in any
direction. If what you suggest above happens in a concise, traceable,
beneficial way to both projects and communities, then I'm for that.

At the same time, I also favor insulation wherever possible and I personally
like the separation of the 2 projects. I have built 10s of projects that
have simply used Lucene as an API and had no need for Solr, and I've built
10s of projects where Solr made perfect sense. So, I appreciate their
separation. I also have a lot of experience in these types of situations as
I've been involved in 2-3 of them over the past few years at NASA in terms
of maintaining separation and merging projects/etc. There are quite a few
lessons learned that I have been trying to share but that have seemingly not
really been appreciated and that have been in my mind dismissed, rather than
discussed, through this process.


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