lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: [jira] Commented: (LUCENE-1473) Implement Externalizable in main top level searcher classes
Date Thu, 04 Dec 2008 13:24:19 GMT

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  

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message