lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: Lucene's default settings & back compatibility
Date Sat, 30 May 2009 11:57:34 GMT
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 <> 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 < 
>> >
>> wrote:
>>> So, here's a real, concrete example of the need for case by case  
>>> back
>>> compat.  See
>>> 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:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message