I think one conclusion that did come of this discussion was that bugs
should be fixed even if it breaks backward compatibility.
-- DM
On May 30, 2009, at 7:21 AM, Michael McCandless wrote:
Actually, I think this is a common, and in fact natural/expected
occurrence in open-source. When a tricky topic is discussed, and the
opinions are often divergent, frequently the conversation never
"converges" to a consensus and the discussion dies. Only if
discussion reaches a semblance of consensus do we vote on it.
It's exactly like what happens when a controversial bill tries to go
through the US congress. It's heavily discussed and then dies off
from lack of consensus, or, it gets far enough to be voted on.
Ie, this is completely normal for open source.
We may not like it, we may consider it inefficient, annoying,
frustrating, whatever, but this is in fact a reality of all healthy
open-source projects.
Consensus building is not easy, and if the number of people trying to
build consensus, by iterating on the proposal, compromising,
suggesting alternatives when others dislike an approach, etc., is
dwarfed by the number of people objecting to the proposal, then
consensus never emerges.
In this case specifically, I had a rather singular goal: the freedom
to make changes to defaults inside Lucene to always favor new users,
while not hurting back-compat users. I intentionally proposed no
changes to our back-compat policy (knowing reaching consensus would be
that much more difficult).
The proposal went through several iterations (*settings,
*actsAsVersion, etc) that all failed to reach consensus, so we settled
back on the current approach of "make the setting explicit" which is
an OK workaround. One by one I've been doing that for the original
examples I listed (readOnly IndexReader, NIOFSDir default, etc.)
But, then, the conversation shifted to a different topic ("how to
relax our back-compat policy"), which also failed to reach consensus.
Maybe, the best way forward is to break out each of the separate
bullets and discuss them separately?
Mike
On Fri, May 29, 2009 at 11:22 PM, Shai Erera <ser...@gmail.com> wrote:
So ... I've this happen a lot of times (especially in my thesis
work) -
someone raises a controversial topic, or one that touches the
nervous of the
system, there's a flurry of activity and then it dies unexpectedly,
even
though it feels to everyone that there's "an extra mile" that
should be
taken in order to bring it to completion.
And that's what I've seen in this thread. A lot has been said -
lots of
comments, ideas, opinions. Lots of ranting and complaining. Then it
died ...
Thank you Grant for that last "beep", I hope that was an intention to
resurrect it.
So I ask - how come that we don't have a decision? Is it because
we're
"afraid" to make a decision? (that last sentence is supposed to
"tease" the
community, not to pass judgement)
I'm asking because it seems like everybody pretty much agrees on
most of the
suggestions, so why not decide "let's do X, Y and Z" and change the
back-compat page starting from 2.9? If people don't remember the
decisions,
I don't mind reiterating them.
(I also ask because I'd like to take the improvements from
LUCENE-1614 to
TermDocs/Positions, PhrasePositions, Spans. All except
PhrasePositions are
public interfaces and so it matters if I need to go through creating
abstract classes, with new names, or I can change those interfaces,
asking
those that implemented their own TermDocs to modify the code).
Shai
On Wed, May 27, 2009 at 10:36 PM, Grant Ingersoll <gsing...@apache.org
>
wrote:
So, here's a real, concrete example of the need for case by case
back
compat. See https://issues.apache.org/jira/browse/LUCENE-1662
It's completely stupid that ExtendedFieldCache even exists. It
is a dumb
workaround for a made up problem that has nothing to do with real
coders
living in the modern age of development where IDE's make
refactoring these
types of things very cheap. Namely, the notion that interfaces
must never
change lest every 6-9 months some minute number of users (I'd
venture it's
less than 1% of users) out there, who by any account are
completely capable
of implementing hard core Lucene internals (like extending
FieldCache), yet
are seemingly incapable of reading a CHANGES file with a huge
disclaimer in
it, have to recompile (GASP!) their code and put in a dummy
implementation
of some new interface method. Yet, here we are with Yonik fixing
very real
problems that are a direct result of coding around back compat.
(along with
a mistake; it took a long time for this issue to even be
discovered) that
very much effect the usability of Lucene and the day to day
experience of a
good number of users.
In other words, the real fix for L-1662 is for ExtFieldCache to be
folded
into FieldCache and for the file to be removed, never to be heard
from
again.
The same can be said for the whole Fieldable issue, but that's a
different
day.
Ranting,
Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
