robert engels wrote:
I think you are incorrect.
I would guess the number of people/organizations using Lucene vs.
contributing to Lucene is much greater.
The contributers work in head (should IMO). The users can select a
particular version of Lucene and code their apps accordingly. They
can also back-port features from a later to an earlier release. If
they have limited development resources, they are probably not
working on Lucene (they are working on their apps), but they can
update their own code to work with later versions - which they
would probably rather do than learning the internals and
contributing to Lucene.
If the users are "just dropping in a new version" they are not
contributing to the community... I think just the opposite, they
are parasites. I think a way to gauge this would be the number of
questions/people on the user list versus the development list.
I don't think they are parasites at all. They are users that place
alot of trust in us and will come to the users list with interesting
issues. Many of the improvements to Lucene are sourced from the
users list. Even if that user doesn't do the actual work to fix the
issue, their innocent question and prodding can inspire someone else
to take the idea forward, make a patch, etc. This is the normal and
healthy way that open source works....
Lucene is a library, and I believe what I stated is earlier is true
- in order to continue to advance it the API needs to be permitted
to change to allow for better functionality and performance. If
Lucene is hand-tied by earlier APIs then this work is either not
going to happen, or be very messy (inefficient).
The thing is, we have been able to advance lately, sizably, without
breaking APIs, thanks to the "future backwards compatibility
proofing" that Lucene does.
I do agree that if it got to the point where we were forced to make a
hard choice of stunt Lucene's growth so as to keep backwards
compatibility vs let Lucene grow and make a new major release, we
should definitely make a new major release. Search is still young
and if we stunt Lucene now it will slowly die.
It's just that I haven't seen any recent change, except for allowing
JVM 1.5 source, that actually requires a major release, I think.
Mike
On Jan 23, 2008, at 3:40 PM, Chris Hostetter wrote:
: I guess I don't see the back-porting as an issue. Only those
that want to need
: to do the back-porting. Head moves on...
I view it as a potential risk to the overal productivity of the
community.
If upgrading from A to B is easy people (in general) won't spend a
lot of
time/effort backporting feature from B to A -- this time/effort
savings
benefits the community because (depending on the person):
1) that time/effort saved can be spend contributing even more
features
to Lucene
2) that time/effort saved improves the impressions people have of
Lucene.
If on the other hand upgrading from X to Y is "hard" that encouragees
people to backport features ... in some cases this backporting may
be done
"in the open" with people contributing these backports as patches,
which
can then be commited/releaseed by developers ... but there is still a
time/effort cost there ... a bigger time/effort cost is the
cummulative
time/effort cost of all the people that backport some set of
features just
enough to get things working for themselves on their local copy,
and don't
contribute thouse changes back ... that cost gets paid by the
commuity s a
whole over and over again.
I certianly don't want to discourage anyone who *wants* to backport
features, and I would never suggest that Lucene should make it a
policy to
not accept patches to previous releases that backport
functionality -- i
just think we should do our best to minimize the need/motivation
to spend
time/effort on backporting.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
