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&[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
