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
