lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Wang" <>
Subject Re: [jira] Commented: (LUCENE-1473) Implement Externalizable in main top level searcher classes
Date Thu, 04 Dec 2008 16:48:53 GMT
Mark and Grant:

    I do apologize if I came off seeming rude. I guess I let my frustration
of the serialization issue got the better of me (and also a built up from
some of the other issues, which I thought are trivial but was made to be
not). And I will improve my behavior in the future.

   There is a reason I have stopped submitting patches via Jira. (For which
I no longer dare to express.)

   There is absolutely nothing wrong with getting paid for Lucene expertise.
I was just commenting on your comment about "volunteering", but if you think
I am wrong, then I am. I did have a concern with the focus of the project
getting biased by paying companies to the committers, but obviously it is
not my business.

    The issues/patches I am having are trivial stuffs, and that was
precisely my point. I am not pushing for  grandeous ideas, I am frustrated
with some very brain dead issues (I am not smart enough to provide any earth
shattering patches) that has blown out of proportion in my mind.

    I will try to keep my mouth shut in the future.


On Thu, Dec 4, 2008 at 5:24 AM, Grant Ingersoll <> wrote:

> On Dec 4, 2008, at 12:36 AM, John Wang wrote:
>  Grant:
>>        I am sorry that I disagree with some points:
>> 1) "I think it's a sign that Lucene is pretty stable." - While lucene is a
>> great project, especially with 2.x releases, great improvements are made,
>> but do we really have a clear picture on how lucene is being used and
>> deployed. While lucene works great running as a vanilla search library, when
>> pushed to limits, one needs to "hack" into lucene to make certain things
>> work. If 90% of the user base use it to build small indexes and using the
>> vanilla api, and the other 10% is really stressing both on the scalability
>> and api side and are running into issues, would you still say: "running well
>> for 90% of the users, therefore it is stable or extensible"? I think it is
>> unfair to the project itself to be measured by the vanilla use-case. I have
>> done couple of large deployments, e.g. >30 million documents indexed and
>> searched in realtime., and I really had to do some tweaking.
> Sorry, we should have written a perfect engine the first time out.  I'll
> get on that.  Question for you:  how much of that tweaking have you
> contributed back?  If you have such obvious wins, put them up as patches so
> we can all benefit, just like you've benefitted from our volunteering.
> As for 90%, I'd say it is more like > 95% and, gee, if I can write a
> general purpose open source search library that keeps 95% of a very, very,
> very large install base happy all while still improving it and maintaining
> backward compatibility, than color me stable.
>> 2) "You want stuff committed, keep it up to date, make it manageable to
>> review, document it, respond to questions/concerns with answers as best you
>> can. " - To some degree I would hope it depends on what the issue is, e.g.
>> enforcing such process on a one-line null check seems to be an overkill. I
>> agree with the process itself, what would make it better is some
>> transparency on how patches/issues are evaluated to be committed. At least
>> seemed from the outside, it is purely being decided on by the committers,
>> and since my understanding is that an open source project belongs to the
>> public, the public user base should have some say.
> Here's your list of opened issues:
 Only 1 of which has more than 2 votes and which is assigned to Hoss.
>  However, from what I can see, you've had all but 1, I repeat ONE, issue not
> resolved.
> And, yes, what gets committed is decided on by the COMMITTERS with input
> from the community; who else can be responsible for committing?  Hence the
> title.  We can't please everyone, but I'll be damned if you're going to
> disparage the work of so many because you have sour grapes over some people
> (not all) disagreeing with you over how serialization should work in Lucene
> just b/c you think the problem is trivial when clearly others do not.
> Committers are picked by the project over a long period of time (feel free
> to nominate someone who you feel has merit, we've elected committers based
> on community nominations in the past) because they stick around and stay
> involved and respond on the list, etc.  I'm starting to think your real
> issue here is that we haven't all agreed with you the minute you suggest
> something, but sorry, that is how open source works.
>> 3) which brings me to this point: "I personally, would love to work on
>> Lucene all day every day as I have a lot of things I'd love to engage the
>> community on, but the fact is I'm not paid to do that, so I give what I can
>> when I can.  I know most of the other committers are that way too." - Is
>> this really true? Isn't a large part of the committer base also a part of
>> the for-profit, consulting business, e.g. Lucid? Would groups/companies that
>> pay for consulting service get their patches/requirements committed with
>> higher priority? If so, seems to me to be a conflict of interest there.
> Yes, John, it is true.  I would love to work on Lucene all day.  If I won
> the lottery tomorrow, I'd probably still volunteer on Lucene.  Let me ask
> you back, who pays you to work on Lucene?  Was this patch submitted because
> you just happened to spot it while pouring over the code at night on your
> own and out of the goodness of your heart?  Or did you discover it at
> LinkedIn where you were specifically hired because of your Lucene skills and
> knowledge of the Lucene community?  In other words, you're accusing me and
> others of getting paid for my expertise in Lucene, all the while you are
> getting paid for your expertise in Lucene.
>> 4) "Lather, rinse, repeat.   Next thing you know, you'll be on the
>> receiving end as a committer." - While I agree that being a committer is a
>> great honor and many committers are awesome, but assuming everyone would
>> want to be a committer is a little presumptuous.
> Where did I imply that?  All I'm saying, is you can't just throw your code
> up here and say "Hey, fix this for me the way I want it fixed and then come
> back and tell me when it's done"  It doesn't work that way.  It never has.
>  No open source project works that way.
>> In conclusion, I hope I didn't unleash any wrath from the committers for
>> expressing candor.
> Hey, we're all entitled to your opinions.  Personally, I think you've made
> a lot of nice contributions to Lucene over the years in terms of insights,
> ideas and patches.  So, I guess I am a bit surprised by the rancor in your
> message, which came from out of no where, not too mention the fact that it
> has completely hijacked an otherwise interesting conversation about the
> right way to do serialization.  If you want to call that candor, than feel
> free.
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message