lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 15:44:55 GMT

On Mar 9, 2010, at 9:48 AM, Mattmann, Chris A (388J) wrote:

> Hey Grant,
> 
> On 3/9/10 5:49 AM, "Grant Ingersoll" <gsingers@apache.org> 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.

Um, I'm a committer.  I've earned the right to apply patches that fit with the project and
I've earned the merit to make that decision.  So have all the other committers.   Besides
the fact, all I would be committing are the things people have already expressed an interest
in anyway.

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

No one is circumventing any process and the implication is just wrong.  We are having the
discussion.  But even so, as a committer, my job is to work within community to fix/improve
the code.  Right now, I see lots of room for improvement in Lucene by integrating some of
those things from Solr (and Nutch) while keeping Lucene, Solr and Nutch whole from an end
user perspective.  At the same time, I want to see Solr and Nutch whole.   Any other implication
is simply wrong.

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

And how at all would those 10 projects be affected at all?  Please read the proposal again.
 It's not like there is going to be some uber JAR.  I won't let it happen as I have more than
10 projects that are pure Lucene.  Part of my day job is supporting Lucene.  I've spent the
past 5 years of my life donating to Lucene, and so have many others.  The argument is simply
invalid and has been refuted so many times now by ALL those who actually do the work that
I don't understand why you insist on bringing it up over and over again.


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

I'd hardly say they've been dismissed.  This isn't about you, it's about what is best for
the project.  You have one opinion, that, by the face of the votes, is in the minority.  It
doesn't make the majority right and you wrong.  In fact, those in the majority are trying
to answer your concerns and come up with a better suggestion.  This is in fact the process
and it is how the ASF works.  This is one of the great things about the Lucene community.
 We have real discussions about the issues.

-Grant
Mime
View raw message