lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 16:46:34 GMT
I'm still +1 for merging Solr/Lucene dev.

I think poaching, when we have so much that needs to be shared, is
going to cause far more problems than it'll solve.  It's not the right
tool for [this] job.

I do think poaching is good & legitimate tool when it's less code (eg
the CommonGrams case), so, we should do both ;)

Mike

On Tue, Mar 9, 2010 at 8:49 AM, Grant Ingersoll <gsingers@apache.org> wrote:
>
> 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:
>>
>>>> If we had that freedom ("poaching is perfectly fine"), then,
>>>> interested devs could freely "refactor" across sub projects.
>>>
>>> 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.
>>
>> But... Lucene should poach from external (eg non-Apache) projects, if
>> the license works?
>>
>> 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.
>
>
>>
>> So we have something of a double standard...
>>
>> 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.
>>
>> 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.
>>
>> 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.
>
> 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
>
>
>
>
>
>
>

Mime
View raw message