Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of gsiasf@gmail.com designates
 209.85.217.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=dyd1ygt8ZyfqcQbzsOMoo2nrH/3KDt17Fc+fJvIh2zJd/EgIb3MTE49pL1As7p0CnJ
         XFpaZq6TS91kukyT2XBch06tfuhu82GEQHkg/F6Lv+dOuoL48XnYBMnqBJgqNxl13WgG
         PU3neRZlYxrqiScRM64huERxlPEwdfQIK547A=
Sender: Grant Ingersoll <gsiasf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: [VOTE] merge lucene/solr development (take 3)
From: Grant Ingersoll <gsingers@apache.org>
In-Reply-To: <9ac0c6aa1003090521s3e6ff4ebp2ee2d749a6770726@mail.gmail.com>
Date: Tue, 9 Mar 2010 08:49:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <CA5A105E-2CE2-45D3-89F2-3A82C8933231@apache.org>
References: <c68e39171003081811o491137fdtc32452f1204a6130@mail.gmail.com>
 <4B95B71D.5050907@gmail.com>
 <c68e39171003081852g69b3fd7cg60e833e27bfaa1bb@mail.gmail.com>
 <FFB888BE-8404-4CF5-BA23-157DD3E28423@apache.org>
 <4B961E80.8070205@getopt.org>
 <9ac0c6aa1003090240k530f5d64u32fc13ec9fc4313c@mail.gmail.com>
 <7509955E-A9BF-4910-A4BD-CEDC863C02E1@apache.org>
 <9ac0c6aa1003090521s3e6ff4ebp2ee2d749a6770726@mail.gmail.com>
To: general@lucene.apache.org


On Mar 9, 2010, at 8:21 AM, Michael McCandless wrote:

> On Tue, Mar 9, 2010 at 7:21 AM, Grant Ingersoll <gsingers@apache.org> =
wrote:
>=20
>>> If we had that freedom ("poaching is perfectly fine"), then,
>>> interested devs could freely "refactor" across sub projects.
>>=20
>> As someone who works on both, I don't think it is fine.  Just look at =
the function query mess.  Just look at the version mess.  It's very =
frustrating as a developer and it makes me choose between two projects =
that I happen to like equally, but for different reasons.  If I worked =
on Nutch, I would feel the same way.
>=20
> But... Lucene should poach from external (eg non-Apache) projects, if
> the license works?
>=20
> Ie if some great analyzer is out there, and Robert spots it, and the
> license works, we should poach it?  (In fact he just did this w/
> Andrzej's Polish stemmer ;) ).

I'd prefer "donate" to poach, but, realize that isn't always the case.


>=20
> So we have something of a double standard...
>=20
> And, ironically, I think it's the fact that there's so much committer
> overlap between Solr and Lucene that is causing this antagonism
> towards poaching.
>=20
> When in fact I think poaching, at a wider scale (across unrelated
> projects) is a very useful means for any healthy open source software
> to evolve.
>=20
> Why should Lucene be prevented from having a useful feature just
> because Solr happened to create it first?

But why should I be forced to maintain two versions due to some =
arbitrary code separation?  And why should you force a good chunk of us =
to do a whole lot of extra work simply because of some arbitrary code =
separation?  Here, it is the Lucene PMC that releases code and it is =
just silly that with all of this overlap at the committer level we still =
have this duplication.   I can't speak for the external projects (I =
don't believe any of them have even responded here other than =
Jackrabbit), but if they don't like it, they should get more involved in =
the community and work to be committers. =20

At any rate, this is exactly why merging makes sense.  You would no =
longer have this issue of "first".  I would no longer have to choose =
where to add my spatial work based on some arbitrary line that someone =
drew in the sand that isn't all that pertinent anymore given the desires =
of most in the community to blur that line.  It would be available to =
everyone.

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.  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.

-Grant