lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Klaas <mike.kl...@gmail.com>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Wed, 10 Mar 2010 00:38:08 GMT
On Mon, Mar 8, 2010 at 8:24 PM, Grant Ingersoll <gsingers@apache.org> wrote:

> It should also be noted that a good chunk of the Solr committers are already Lucene committers,
and of the remaining there are: Bill Au, Mike Klaas, Ryan McKinley, Shalin and Noble.  Mike
has been inactive for quite some time (and has elected to go emeritus even though it's not
marked on the page) and and Ryan, Shalin and Noble already contribute to Lucene in various
parts (AFAICT), so to me it's not a big stretch to say bring them into the fold.  I haven't
tracked Bill's involvement, but I also know Bill and trust he knows what it means to be a
committer, i.e. he knows as much what not to touch as what to touch.  Of course, we can do
a separate vote on that if that helps satisfy Chris' issue on the committers.

I don't expect that it makes much of a difference either way, but feel
free to leave me out of the Lucene auto-committership should that be
an issue.  I don't expect to become an active committer in the near
future.

> In the end, for me anyway, the current separation hurts Lucene a good deal as much as
it hurts Solr, if not more.

Agreed.

The central issue is that Solr committers often work on features which
are core to "full-text search" rather than "an HTTP full-text search
server".  The parts of the features related to full-text search would
improve Lucene (the fact that Solr is used by people as a library in
an embedded context provides glaring testament to that).  But they
don't end up there, due to the friction of simultaneously developing a
feature in two projects that aren't synchronized.

Does this happen often?  It does.  I'd say over 50% of my non-trivial
changes to Solr could have been useful in Lucene.  (This is probably
not representative of the entire Solr committerdom, of course.)  In
fact, the *very first patch* I developed for Solr was adding in hit
highlighting, and I ended up copy&pasting a class from contrib
Highlighter to extend it.  Of course, I was a committer for neither
project at the time; I don't want to think about the logistics of
trying to submit patches to both projects which are so inter-dependent
(and would pretty much rely on review by someone who was a committer
on both projects anyway).

I think someone could make an argument that I should have been more
conscientious about submitting patches to Lucene, and they are
probably right.  But, I ultimately wasn't, and many other committers
weren't as well (even those who were committers for both projects),
and so we've ended up in this situation where we really have *three*
projects:  Lucene, the java search library, Lucene+, the set of
improvements and extensions to Lucene which could be in Lucene itself
and developed by the same people as Lucene, and Solr, the HTTP server
around Lucene.

The Lucene Project as a whole would benefit if this situation were
improved.  Auto-syncing Lucene-trunk with Solr would bring an
improvement, but it isn't a fundamental solution and has its own set
of problems.  The current proposal seems reasonable, but I worry about
the level of contention it is receiving.

+0

-Mike

Mime
View raw message