Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 70074 invoked from network); 4 Dec 2008 13:25:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Dec 2008 13:25:24 -0000 Received: (qmail 35002 invoked by uid 500); 4 Dec 2008 13:25:34 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 34826 invoked by uid 500); 4 Dec 2008 13:25:33 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 34817 invoked by uid 99); 4 Dec 2008 13:25:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Dec 2008 05:25:33 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [208.97.132.119] (HELO spunkymail-a17.g.dreamhost.com) (208.97.132.119) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Dec 2008 13:24:04 +0000 Received: from [192.168.0.3] (adsl-074-229-189-244.sip.rmo.bellsouth.net [74.229.189.244]) by spunkymail-a17.g.dreamhost.com (Postfix) with ESMTP id 5403673479 for ; Thu, 4 Dec 2008 05:24:20 -0800 (PST) Message-Id: <2857831D-BC28-4EE7-AD2E-8703A2025BCF@apache.org> From: Grant Ingersoll To: java-dev@lucene.apache.org In-Reply-To: <8837fb770812032136y6469c7fdyefbc52245b9a3d8@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [jira] Commented: (LUCENE-1473) Implement Externalizable in main top level searcher classes Date: Thu, 4 Dec 2008 08:24:19 -0500 References: <285450834.1228332464360.JavaMail.jira@brutus> <57AB459A-5FD8-4F90-8D04-E0EC170A5FEF@apache.org> <8837fb770812032136y6469c7fdyefbc52245b9a3d8@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org 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: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=john.wang@gmail.com 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: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org