Re: Version 1.9

Scott Ganyo wrote: What is required to make the release? The (somewhat dated) steps are at: http://wiki.apache.org/jakarta-lucene/ReleaseTodo Probably the first thing to do is to update these (cvs -> svn) and see if folks suggest any other improvements. We should start with a 1.9-rc1 relea

Re: Version 1.9

i'm willing to help out On 9/13/05, Scott Ganyo <[EMAIL PROTECTED]> wrote: > What is required to make the release? > > On Sep 12, 2005, at 3:39 PM, Erik Hatcher wrote: > > > > > On Sep 12, 2005, at 1:55 PM, Doug Cutting wrote: > > > >> Erik Hatcher wrote: > >> > >> > >>> I'm using the trunk of S

Re: Version 1.9

What is required to make the release? On Sep 12, 2005, at 3:39 PM, Erik Hatcher wrote: On Sep 12, 2005, at 1:55 PM, Doug Cutting wrote: Erik Hatcher wrote: I'm using the trunk of Subversion (pretty much what 1.9 will be) on all my projects and it is quite stable. I defer to the other

DO NOT REPLY [Bug 36628] - Make FieldSortedHitQueue public

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36628] New: - Make FieldSortedHitQueue public

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Version 1.9

On Sep 12, 2005, at 1:55 PM, Doug Cutting wrote: Erik Hatcher wrote: I'm using the trunk of Subversion (pretty much what 1.9 will be) on all my projects and it is quite stable. I defer to the others on when we release it as 1.9 officially, though. I think the 1.9 release should be ma

DO NOT REPLY [Bug 36623] - RAMInputStream without further buffering

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36623] - RAMInputStream without further buffering

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36623] New: - RAMInputStream without further buffering

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36622] New: - Reducing buffer sizes for TermDocs.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: Fwd: [jira] Commented: (INFRA-199) Convert Lucene's Bugzilla to JIRA

Erik Hatcher wrote: I haven't seen this come across the java-dev list (I could have missed it though). Everyone ok with moving to JIRA? +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL P

Re: Version 1.9

Erik Hatcher wrote: I'm using the trunk of Subversion (pretty much what 1.9 will be) on all my projects and it is quite stable. I defer to the others on when we release it as 1.9 officially, though. I think the 1.9 release should be made soon. What is required is a motivated committer wit

Re: Delaying buffer allocation in BufferedIndexInput

Paul Elschot wrote: I tried delaying the buffer allocation in BufferedIndexInput by using this clone() method: public Object clone() { BufferedIndexInput clone = (BufferedIndexInput)super.clone(); clone.buffer = null; clone.bufferLength = 0; clone.bufferPosition = 0; clone.

Corrupted Index

I've been looking into whether or not it is possible the check a Lucene index for corruption. It doesn't matter how the corruption occurs, from JVM crashes, bad file copying or whatever. I found an old thread in this mailing list on the subject, which was from before Lucene 1.2, over 3 years ago

RE: corrupted index

I've been looking into whether or not it is possible the check a Lucene index for corruption. It doesn't matter how the corruption occurs, from JVM crashes, bad file copying or whatever. I found an old thread in this mailing list on the subject, which was from before Lucene 1.2, over 3 years ago