Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Mattmann, Chris A (388J)" <chris.a.mattmann@jpl.nasa.gov>
To: "general@lucene.apache.org" <general@lucene.apache.org>
Date: Thu, 4 Mar 2010 11:09:20 -0800
Subject: Re: [VOTE] merge lucene/solr development
Thread-Topic: [VOTE] merge lucene/solr development
Thread-Index: Acq7yuKF1A8VvADTQ5GCSOoYgHlFggAA07ho
Message-ID: <C7B54560.D812%Chris.A.Mattmann@jpl.nasa.gov>
In-Reply-To: <Pine.LNX.4.64.1003041035410.23212@radix.cryptio.net>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Hoss,

>=20
> : If Solr is not on Lucene trunk, that's not going to happen.
> :
> : Solr on Lucene trunk is key. Release cycles is key to that.
> :
> : Build process is key to getting devs that stick in one world to branch =
into
> : the other just a bit.
>=20
> Then approach the problem top down instead of bottom up: If this solr-dev
> community is in general on board with the "merge" end goal, it shouldn't
> be hard to get a lot of solr commiters to work on modifying the Solr
> build process so it starts using Lucene trunk (or Lucene nightlies) and
> commiting hte changes to Solr to get that to compile/run properly -- if
> there are Lucene-Java changes neccessay to make that work, then those
> Solr-devs can submit patches back.

Agreed, +1, why does there need to be some type of (potentially) sweeping
memorandum in place to ensure this happens?

>=20
> As you said in your last email "If they should be a commiter, they would
> contribute to the project and become one naturally" ... so why not just
> let nature take it's course?  If the Solr community moves it's build
> process to be tightly bound with the LUcene one *then* it can make sense
> to talk about lock step releases, and shared dev lists, etc...

+1 again and this is also one of my main objections to the proposal as it
stands. Let the community decide who the committers are, and let each
community decide what version of software it depends on. I'm not convinced
that they are the same communities for that matter, and statements made
earlier about Solr being the biggest user of Lucene(-java) may be true from
a Lucene ecosystem perspective, but I disagree it's true (or even provable
for that matter) from an external perspective given Lucene(-java)'s
widespread use predating Solr as an Apache project, and Lucene's infection
into other communities (e.g., PHP with Zend, etc.)

>=20
> I honestly don't care which direction we go, but we should be able do thi=
s
> incrementally -- if we can't, then we probably can't do it in one fell
> swoop either.
>=20
> As I said: The whole thing feels like we're voting on a "goal" -- Goals
> are nice in that they give us an end point to aim for, but I can't
> remember any time we've ever voted on a "goal" ... this situation (saying
> "it would be really great to eventually be/have _____" so let's just set
> out to do that") doesn't feel like any change that's ever turned out well
> in Lucene.=20
>=20
> Things that have worked well in the past have been incremental and
> iterative.

+1.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++