Re: Lucene's default settings & back compatibility

> > With the new way, you can get the first bug fix release, but then you will > quickly be left out of new bug fixes until you update your code. Mark, apologies for the late reference, but it struck me only after I left the computer yesterday. Again, I'm not sure how bit of a problem is it. Supp

[jira] Updated: (LUCENE-1650) Small fix in CustomScoreQuery JavaDoc

[ https://issues.apache.org/jira/browse/LUCENE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-1650: Attachment: customScoreQuery_CodeChange+JavaDoc.patch customScoreQuery_Java

[jira] Created: (LUCENE-1650) Small fix in CustomScoreQuery JavaDoc

Small fix in CustomScoreQuery JavaDoc - Key: LUCENE-1650 URL: https://issues.apache.org/jira/browse/LUCENE-1650 Project: Lucene - Java Issue Type: Improvement Components: Javadocs Affects Ver

Re: Lucene's default settings & back compatibility

On May 20, 2009, at 4:06 PM, Michael McCandless wrote: On Wed, May 20, 2009 at 3:24 PM, Shai Erera wrote: Then why go through all this trouble and not simply change the back- compat policy? Back-compat is insanely costly, especially the longer it takes us to get to the next major release..

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711444#action_12711444 ] Erik van Zijst commented on LUCENE-1474: Running with the patch applied doesn't se

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711437#action_12711437 ] Michael McCandless commented on LUCENE-1474: Sorry, 2.4.1 > Incorrect Segment

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711436#action_12711436 ] Erik van Zijst commented on LUCENE-1474: Should that be applied to tags/lucene_2_4

[jira] Created: (LUCENE-1649) numerical problem associated with CustomScoreQuery, ValueSourceQuery

numerical problem associated with CustomScoreQuery, ValueSourceQuery Key: LUCENE-1649 URL: https://issues.apache.org/jira/browse/LUCENE-1649 Project: Lucene - Java Issue Ty

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711424#action_12711424 ] Michael McCandless commented on LUCENE-1474: OK, thanks. Let's try this: {cod

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711418#action_12711418 ] Erik van Zijst commented on LUCENE-1474: Sure, I'd be happy to. > Incorrect Segme

[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one

[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711412#action_12711412 ] Trejkaz commented on LUCENE-1646: - I guess that's true if you look at exceptions as a logg

[jira] Updated: (LUCENE-1648) when you clone or reopen an IndexReader with pending changes, the new reader doesn't commit the changes

[ https://issues.apache.org/jira/browse/LUCENE-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1648: --- Attachment: LUCENE-1648.patch Attached patch... I plan to commit in a day or two. >

[jira] Commented: (LUCENE-1648) when you clone or reopen an IndexReader with pending changes, the new reader doesn't commit the changes

[ https://issues.apache.org/jira/browse/LUCENE-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711388#action_12711388 ] Michael McCandless commented on LUCENE-1648: bq. I wonder if the only two test

[jira] Commented: (LUCENE-1648) when you clone or reopen an IndexReader with pending changes, the new reader doesn't commit the changes

[ https://issues.apache.org/jira/browse/LUCENE-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711378#action_12711378 ] Earwin Burrfoot commented on LUCENE-1648: - I wonder if the only two tests I still

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: That said, I see the points and value of relaxing the back compat policy as well. Its been discussed a lot in the past, and it has been eased in the past. Afraid to ask which additional shackles Lucene bore in the past. :) The easing wasn't that match. Offhand, I rem

Re: Lucene's default settings & back compatibility

> That said, I see the points and value of relaxing the back compat policy as > well. Its been discussed a lot in the past, and it has been eased in the past. Afraid to ask which additional shackles Lucene bore in the past. I mean, 'what' has to be eased to produce policies we have right now? Joki

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 4:31 PM, Shai Erera wrote: > A personal example - I wrote an Analyzer which includes lots of code (lots > of TokenFilters, Tokenizers etc.). Then I see that the whole TokenStream API > is deprecated and will be replaced. Yeah, that one is going to be causing some headaches

Re: Lucene's default settings & back compatibility

Shai Erera wrote: Thats not really the style Lucene has taken in the past :) Is it a back-compat policy? Maybe it's time to change that too ;) (kidding) Shai On Wed, May 20, 2009 at 11:39 PM, Mark Miller > wrote: Thats not really the style Lucene has

Re: Lucene's default settings & back compatibility

> > Thats not really the style Lucene has taken in the past :) Is it a back-compat policy? Maybe it's time to change that too ;) (kidding) Shai On Wed, May 20, 2009 at 11:39 PM, Mark Miller wrote: > Thats not really the style Lucene has taken in the past :) >

Re: Adding clear() to Document

I'm actually not after any performance improvements, just after convenience. Like I said, today I have an awkward way to do clear(), instead I want to add clear() which will do a simple fields.clear(). Since Document keeps an ArrayList of fields, calling clear() on it is not that expensive (nulling

Re: Lucene's default settings & back compatibility

Shai Erera wrote: When the flood gates open, and code is rolling all over the place, upgrading Lucene becomes less of a buffet and more of a pain in the a** I slightly disagree with that. If I'm a 2.2 user and I silently upgraded to 2.4, 2.4.1 and 2.9 I will have loads of work to

Re: Lucene's default settings & back compatibility

> > When the flood gates open, and code is rolling all over the place, > upgrading Lucene becomes less of a buffet and more of a pain in the a** > I slightly disagree with that. If I'm a 2.2 user and I silently upgraded to 2.4, 2.4.1 and 2.9 I will have loads of work to do when I come to upgrade t

Re: Adding clear() to Document

Compared to caching and passing in a List to the Document constructor, I imagine a clear() based solution would be slower... there's more work to do. clear() needs to null the pointers, and then one needs to add the fields again, one-by-one. But I doubt we'd be able to detect a variance anyway, g

Re: Lucene's default settings & back compatibility

Shai Erera wrote: +1 (am I allowed to cast +1s not being a committer?) :) Absolutely :) When push comes to shove, you don't even have a valid vote as a Committer. Only members of the PMC have binding votes. You have as much voting power as a committer as long as you have as much an ability t

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711315#action_12711315 ] Shai Erera commented on LUCENE-1614: bq. Though it's yet another example of how we hur

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: See, you upgrade either for new features, or for performance improvements. You have to write code for former, and you have to write code for the latter (because by default most of them are off). Mark Miller: If you have upgraded Lucene over the years and you never t

Re: Lucene's default settings & back compatibility

Earwin - I wrote it before - index structure is the only back-compat policy I propose to keep, and not for just one major release, but for 2 (which I believe is the current behavior already). I also absolutely don't want to give that up. I think it's not unreasonable to say "if you want to take ad

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711311#action_12711311 ] Michael McCandless commented on LUCENE-1614: bq. Maybe there's a way out of th

Re: Adding clear() to Document

I came across this while working on 1595 (changes to benchmark). I noticed LineDocMaker reuses Document and Fields, and I wanted to pull that up to a base DocMaker since I got the impression it yields better (even if not significant) performance. With the addition of the Field ctor which accepts a

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 3:24 PM, Shai Erera wrote: > Then why go through all this trouble and not simply change the back-compat > policy? OK so let's talk policy now ;) We need some serious relaxing of the back-compat policy to make the actsAsVersion proposal pointless. Ie whenever we want to c

Re: Lucene's default settings & back compatibility

Mark Miller: > If you have upgraded Lucene over the years and you never touched code to > tweak performance, you still got fantastic performance improvements. You just > didn't get them all. If you never touched the code over the years, your project is probably already dead. Shai Erera: > Exactl

Re: Adding clear() to Document

On Wed, May 20, 2009 at 3:27 PM, Shai Erera wrote: > I noticed Document does not have a clear() method, to remove all the Fields > set on it. Document's state is so simple (a List and a boost), reuse doesn't seem worth it. What if, instead, we allowed the List to be passed into via Document's con

Re: Lucene's default settings & back compatibility

Exactly ! which is why I think we should relax the back-compat policy "a bit". And ... (I realize it's going to complicate things a bit) we could also decide to have dot release for bug fixes, like we had 2.4.1. So let's say when 3.4 comes (3-4 years from now :) ). In 3.6 we don't preserve any bac

[jira] Resolved: (LUCENE-1645) Deleted documents are visible across reopened MSRs

[ https://issues.apache.org/jira/browse/LUCENE-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1645. Resolution: Fixed > Deleted documents are visible across reopened MSRs > -

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: See, you upgrade either for new features, or for performance improvements. You have to write code for former, and you have to write code for the latter (because by default most of them are off). Thats not completely true. If you have upgraded Lucene over the years and you

[jira] Commented: (LUCENE-1645) Deleted documents are visible across reopened MSRs

[ https://issues.apache.org/jira/browse/LUCENE-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711305#action_12711305 ] Michael McCandless commented on LUCENE-1645: Looks good... I'll commit shortly

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711303#action_12711303 ] Shai Erera commented on LUCENE-1614: Maybe there's a way out of this. In 2.9 we're alr

Re: Lucene's default settings & back compatibility

In fact, there's no reason to upgrade Lucene (save for bigfixes), if you absolutely require a drop-in jar, and don't want to touch any of your code. See, you upgrade either for new features, or for performance improvements. You have to write code for former, and you have to write code for the latte

Adding clear() to Document

I noticed Document does not have a clear() method, to remove all the Fields set on it. If we want to encourage the reuse of Document and Field, I think it's a required method. We do have remove* versions, but no clear(). BTW, I noticed that Field's constructors check for null value and throw an ex

Re: Lucene's default settings & back compatibility

Then why go through all this trouble and not simply change the back-compat policy? Really, I read some of Grant's responses and I realize that I've upgraded to 2.4 way too long ago. 2.9 is nowhere in sight. It takes a lot of time to release and during that time there's lots of discussions on the m

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 12:55 PM, Andi Vajda wrote: > I've been watching this thread with interest with my opinion swaying back > and forth. So have I! > This last comment, though, pushes me to favor the settings class idea > because that idea came with the promise of eliminating the combinator

[jira] Updated: (LUCENE-1645) Deleted documents are visible across reopened MSRs

[ https://issues.apache.org/jira/browse/LUCENE-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Earwin Burrfoot updated LUCENE-1645: Attachment: LUCENE-1645.patch Here's the fix. Plus slightly modified test that fails witho

[jira] Created: (LUCENE-1648) when you clone or reopen an IndexReader with pending changes, the new reader doesn't commit the changes

when you clone or reopen an IndexReader with pending changes, the new reader doesn't commit the changes --- Key: LUCENE-1648 URL: https://issues.apache.org/jira/br

Re: Lucene's default settings & back compatibility

On Wed, 20 May 2009, Michael McCandless wrote: On Wed, May 20, 2009 at 11:57 AM, Yonik Seeley wrote: On Wed, May 20, 2009 at 11:46 AM, Mark Miller wrote: Marvin Humphrey wrote: Yeesh, that's evil.  :( It will be sweet, sweet justice if one of your own projects gets infected by the kind o

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 11:57 AM, Yonik Seeley wrote: > On Wed, May 20, 2009 at 11:46 AM, Mark Miller wrote: >> Marvin Humphrey wrote: >>> >>> Yeesh, that's evil.  :( >>> >>> It will be sweet, sweet justice if one of your own projects gets infected >>> by >>> the kind of action-at-a-distance bug

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 11:46 AM, Mark Miller wrote: > Marvin Humphrey wrote: >> >> Yeesh, that's evil.  :( >> >> It will be sweet, sweet justice if one of your own projects gets infected >> by >> the kind of action-at-a-distance bug you're so blithely unconcerned about > > Heh. Thats a bit over t

Re: Lucene's default settings & back compatibility

Marvin Humphrey wrote: Yeesh, that's evil. :( It will be sweet, sweet justice if one of your own projects gets infected by the kind of action-at-a-distance bug you're so blithely unconcerned about Heh. Thats a bit over the top. It is evil stuff, but its much less evil in this very contained in

[jira] Updated: (LUCENE-1647) IndexReader.undeleteAll can mess up the deletion count stored in the segments file

[ https://issues.apache.org/jira/browse/LUCENE-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1647: --- Attachment: LUCENE-1647.patch Test case showing the issue. > IndexReader.undeleteAl

[jira] Created: (LUCENE-1647) IndexReader.undeleteAll can mess up the deletion count stored in the segments file

IndexReader.undeleteAll can mess up the deletion count stored in the segments file -- Key: LUCENE-1647 URL: https://issues.apache.org/jira/browse/LUCENE-1647 Project: Luc

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711188#action_12711188 ] Michael McCandless commented on LUCENE-1474: Are you able to run a modified Lu

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711187#action_12711187 ] Michael McCandless commented on LUCENE-1614: bq. I think that doing what you p

[jira] Commented: (LUCENE-1645) Deleted documents are visible across reopened MSRs

[ https://issues.apache.org/jira/browse/LUCENE-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711185#action_12711185 ] Michael McCandless commented on LUCENE-1645: bq. IFF the subreader being clone

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 05:57:49PM +0400, Earwin Burrfoot wrote: > > What happens when two libraries loaded in the same VM have Lucene as a > > dependency and set actsAsVersion to conflicting numbers? > Exactly what happens when you call BooleanQuery.setMaxClauseCount(n) > from two libraries. > L

[jira] Commented: (LUCENE-1550) Add N-Gram String Matching for Spell Checking

[ https://issues.apache.org/jira/browse/LUCENE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711150#action_12711150 ] Grant Ingersoll commented on LUCENE-1550: - Committed revision 776704. Thanks Tom!

Re: Lucene's default settings & back compatibility

Exactly what happens when you call BooleanQuery.setMaxClauseCount(n) from two libraries. Last one wins. On Wed, May 20, 2009 at 17:50, Marvin Humphrey wrote: >> But since 3.0 is a major release anyway, we could change the default >> of actsAsVersion with each 3.x release (or just set it to 3)

Re: Lucene's default settings & back compatibility

> But since 3.0 is a major release anyway, we could change the default > of actsAsVersion with each 3.x release (or just set it to 3) and > require that a users set actsAsVersion=3 (or whatever version they > are on) in order to get maximum back compatibility. What happens when two librari

[jira] Commented: (LUCENE-1645) Deleted documents are visible across reopened MSRs

[ https://issues.apache.org/jira/browse/LUCENE-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711139#action_12711139 ] Earwin Burrfoot commented on LUCENE-1645: - bq. Right; I think we should simply clo

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 8:28 AM, Yonik Seeley wrote: >> So I think you're suggesting something like this: when you use Lucene, >> if you want "latest and greatest" defaults, do nothing. >> >> If instead you want defaults to match a particular past minor release, >> you must call (say) LuceneVersi

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711128#action_12711128 ] Shai Erera commented on LUCENE-1614: Regarding my previous post on back-compat, maybe

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711120#action_12711120 ] Shai Erera commented on LUCENE-1614: Actually, as I read the "back-compat discussion",

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711121#action_12711121 ] Michael McCandless commented on LUCENE-1614: I think I'd favor not nulling req

Re: Lucene's default settings & back compatibility

I like the idea of settings however it is implemented. With the blurring of core and contrib in the repackaging of Lucene, the issue of backward compatibility becomes more difficult. (maybe, I'm imagining problems where they don't exist.) My concern with any of these mechanisms: codifying p

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 7:22 AM, Michael McCandless wrote: > So I think you're suggesting something like this: when you use Lucene, > if you want "latest and greatest" defaults, do nothing. > > If instead you want defaults to match a particular past minor release, > you must call (say) LuceneVersi

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Tue, May 19, 2009 at 4:50 PM, Yonik Seeley wrote: Right, that's exactly why I want to fix it (only one behavior allowed and so for all of 2.* we must match the 2.0 behavior). I meant one jar per per-jvm gives you one behavior (as is the case now). But by

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711107#action_12711107 ] Erik van Zijst commented on LUCENE-1474: {quote} Erik, do you use undeleteAll? I'v

Re: Lucene's default settings & back compatibility

On Tue, May 19, 2009 at 4:50 PM, Yonik Seeley wrote: >> Right, that's exactly why I want to fix it (only one behavior allowed >> and so for all of 2.* we must match the 2.0 behavior). > > I meant one jar per per-jvm gives you one behavior (as is the case now). > But by setting a static actsAs ver

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711097#action_12711097 ] Shai Erera commented on LUCENE-1614: Thanks Mike for the clarification. One thing thou

[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one

[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711096#action_12711096 ] Michael McCandless commented on LUCENE-1646: I agree it's bad that the root ca

Re: Lucene's default settings & back compatibility

On May 19, 2009, at 1:51 PM, Michael McCandless wrote: I think you've moved onto discussing something different: should we relax our back compat policy. I'm all for that discussion, but it's different from "given our back compat policy, how can we implement it w/o harming new users of Lucene".

[jira] Commented: (LUCENE-1474) Incorrect SegmentInfo.delCount when IndexReader.flush() is used

[ https://issues.apache.org/jira/browse/LUCENE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711090#action_12711090 ] Michael McCandless commented on LUCENE-1474: Erik, do you use undeleteAll? I'

[jira] Commented: (LUCENE-1645) Deleted documents are visible across reopened MSRs

[ https://issues.apache.org/jira/browse/LUCENE-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711086#action_12711086 ] Michael McCandless commented on LUCENE-1645: bq. Lazy clone() is a bad idea, s

[jira] Commented: (LUCENE-1614) Add next() and skipTo() variants to DocIdSetIterator that return the current doc, instead of boolean

[ https://issues.apache.org/jira/browse/LUCENE-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711082#action_12711082 ] Michael McCandless commented on LUCENE-1614: I'm not referring to BS/2's expos