lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [VOTE] merge lucene/solr development (take 3)
Date Tue, 09 Mar 2010 16:00:02 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" <> 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.

Then it's not an issue, right? Additionally, you didn't really answer my
question to what the cause of it not happening is (resources/time/process?)

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

Sweeping proposals with TBDs leave room for implications. Smaller, concrete
steps do not.

>> 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 think the point that you and some others are missing is that JARs are not
the only artifact of a system. Just as you develop in Lucene "officially" as
an ASF committer for Lucene(-java), and just as you and others develop in
Solr "officially" as Solr ASF committers, it doesn't mean others don't also
develop using the same code on their own projects. JARs are not the only
artifact that is being reused.

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

It's extremely unclear to me about how you can be so sure about how
something will work when there have been many questions, the proposal itself
includes TBDs or things as Yonik put it that "will be figured out later."

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

Well I'm sorry you feel that way. However, like I said it seems to be like
the discussion of the real issues is only happening recently over the past
few days. There has been a lot of effort to push this through before then.

> It doesn't make the majority right and you wrong.

Appreciate it, in fact I'm not looking to assign right and wrong.

> In fact, those in the majority are trying to answer your concerns and come up
> with a better suggestion.

The recent discussions have been picked up and I am feeling like we're
starting to discuss the issues so that's a good thing.


Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message