Build failed in Hudson: Lucene-trunk #359

See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/359/changes -- [...truncated 922 lines...] A contrib/swing/src/test/org/apache/lucene/swing/models/TestUpdatingList.java A contrib/swing/src/test/org/apache/lucene/swing/models/List

Build failed in Hudson: Lucene-trunk #358

See http://hudson.zones.apache.org/hudson/job/Lucene-trunk/358/changes -- [...truncated 752 lines...] A contrib/snowball/src/java/net A contrib/snowball/src/java/net/sf A contrib/snowball/src/java/net/sf/snowball AUcontrib/sno

Re: Back Compatibility

+1. And, we always have the major version release at our disposal if need be. At any rate, I think we have beaten this one to death. I think it is a useful to look back every now and then on the major things that guide us and make sure we all still agree, at least for the most part. F

Re: Back Compatibility

+1 On Jan 27, 2008, at 8:34 PM, Chris Hostetter wrote: : But I do agree, benchmark doesn't have the same litmus test. the generalization of that statement probably being "all contribs are not created equal." I propose making some comments in the BackwardsCompatibility wiki page about the c

Re: Back Compatibility

And then you can end up like the Soviet Union... The basic problems of communism - those that don't contribute their fair share, but suck out the minimum resources (but maximum in totality), and those that want to lead (their contribution) and suck the minimum, and then those that contribut

Re: Back Compatibility

: But I do agree, benchmark doesn't have the same litmus test. the generalization of that statement probably being "all contribs are not created equal." I propose making some comments in the BackwardsCompatibility wiki page about the compatibility commitments of contribs depends largely on the

Re: Back Compatibility

: > So, in hindsight, the acronym/host setting for StandardAnalyzer really : > should have defaulted to "true", meaning the bug is fixed, but users who : > somehow depend on the bug (which should be a tiny minority) have an avenue : > (setReplaceInvalidAcronym) to keep back compatibility if needed

Re: Back Compatibility

: 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

[jira] Updated: (LUCENE-1132) Highlighter Documentation updates

[ https://issues.apache.org/jira/browse/LUCENE-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated LUCENE-1132: Attachment: LUCENE-1132.patch Update for highlighter. Deprecates byte related stuff in f

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

[ https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563001#action_12563001 ] Steven Rowe commented on LUCENE-1157: - bq. I think it should not be too difficult now

Re: formatable changes log

I switched to maintaining the CHANGES file in YAML format for the solr-ruby library: There is even a unit test to make sure it at least parses properly:

[jira] Commented: (LUCENE-997) Add search timeout support to Lucene

[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562972#action_12562972 ] Paul Elschot commented on LUCENE-997: - In the timeout.patch, instead of this: {code} ti

[jira] Commented: (LUCENE-997) Add search timeout support to Lucene

[ https://issues.apache.org/jira/browse/LUCENE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562964#action_12562964 ] Timo Nentwig commented on LUCENE-997: - @Sean: "The biggest changes are that it uses a l