Michael McCandless wrote:
> There is the debate about multi/single sort API, but that will take
> time to net out, and I don't the we should block 2.9.1's bug fixes for
> that...
>
> Mike
Certainly not! A couple of those bugs are quite nasty - lets release the
relief!
--
- Mark
http://www.lucidi
On Mon, Oct 26, 2009 at 6:07 AM, Uwe Schindler wrote:
> In the 3.0's backwards info! In 2.9.1 all stays as usual.
Right :) I'll start the 2.9.1 release process...
> I was a little bit confused this morning, because I have seen no relation
> between 2.9.1 and compress removal. It was under discu
ay, October 26, 2009 11:00 AM
> To: java-dev@lucene.apache.org
> Subject: Re: 2.9.1
>
> On Mon, Oct 26, 2009 at 1:21 AM, Michael Busch wrote:
> > Yeah, if everyone else is okay with the one-time performance hit during
> > merge (details in LUCENE-1960), then I'm also +1
On Mon, Oct 26, 2009 at 1:21 AM, Michael Busch wrote:
> Yeah, if everyone else is okay with the one-time performance hit during
> merge (details in LUCENE-1960), then I'm also +1 for cutting 2.9.1 tomorrow!
I think this is acceptable, but we should call it out clearly in the
"changes to back comp
Yeah, if everyone else is okay with the one-time performance hit during
merge (details in LUCENE-1960), then I'm also +1 for cutting 2.9.1 tomorrow!
Michael
On 10/25/09 5:37 PM, Michael McCandless wrote:
Uwe, or anyone, any objections to cutting a 2.9.1 RC tomorrow? It
looks like LUCENE-1960
> Sent: Monday, October 26, 2009 1:38 AM
> To: java-dev@lucene.apache.org
> Subject: Re: 2.9.1
>
> Uwe, or anyone, any objections to cutting a 2.9.1 RC tomorrow? It
> looks like LUCENE-1960 is going to go with the decompress-on-merge
> option?
>
> Mike
>
> On Fri,
Uwe, or anyone, any objections to cutting a 2.9.1 RC tomorrow? It
looks like LUCENE-1960 is going to go with the decompress-on-merge
option?
Mike
On Fri, Oct 23, 2009 at 6:00 PM, Uwe Schindler wrote:
> I try to get the rest of search deprecations away in 3.0, but then we should
> be sure, that
> Well, we should then have added it to 2.9.0 already. Normally we don't
> introduce new APIs in bugfix releases.
>
> This could be a candidate for the backwards-compat break section: If you
> have compressed fields you need to change your code, otherwise drop-in
> will work.
2.9.1 already has s
On 10/23/09 3:19 PM, Uwe Schindler wrote:
Open is still the problem with compressed fields (see LUCENE-1960), if
we
use option 3 (isCompressed() deprec method, we have to add it to 2.9,
too ->
I would not prefer this).
See the issue for details. I do not w
> > Open is still the problem with compressed fields (see LUCENE-1960), if
> we
> > use option 3 (isCompressed() deprec method, we have to add it to 2.9,
> too ->
> > I would not prefer this).
See the issue for details. I do not want to add this method, as it would
break bw compatibility in 2.9 if
On 10/23/09 3:00 PM, Uwe Schindler wrote:
I try to get the rest of search deprecations away in 3.0, but then we should
be sure, that there are no more such problems like with the posIncrement in
QueryParser that need additional changes in 2.9.1 API.
Maybe somebody can help me with the rest of LU
> On Fri, Oct 23, 2009 at 6:00 PM, Uwe Schindler wrote:
> > I try to get the rest of search deprecations away in 3.0, but then we
> should
> > be sure, that there are no more such problems like with the posIncrement
> in
> > QueryParser that need additional changes in 2.9.1 API.
>
> That sounds l
On Fri, Oct 23, 2009 at 6:00 PM, Uwe Schindler wrote:
> I try to get the rest of search deprecations away in 3.0, but then we should
> be sure, that there are no more such problems like with the posIncrement in
> QueryParser that need additional changes in 2.9.1 API.
That sounds like a big job th
I try to get the rest of search deprecations away in 3.0, but then we should
be sure, that there are no more such problems like with the posIncrement in
QueryParser that need additional changes in 2.9.1 API.
Maybe somebody can help me with the rest of LUCENE-1973, the rest is
explain() in Scorer (
ccandless.com]
>> Sent: Monday, October 19, 2009 6:03 PM
>> To: java-dev@lucene.apache.org; yo...@lucidimagination.com
>> Subject: Re: 2.9.1
>>
>> On Mon, Oct 19, 2009 at 11:54 AM, Yonik Seeley
>> wrote:
>> > On Wed, Oct 14, 2009 at 5:39 PM, Michael McCand
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Monday, October 19, 2009 6:03 PM
> To: java-dev@lucene.apache.org; yo...@lucidimagination.com
> Subject: Re: 2.9.1
>
> On Mon, Oct 19, 2009 at 11:54 AM,
On Mon, Oct 19, 2009 at 11:54 AM, Yonik Seeley
wrote:
> On Wed, Oct 14, 2009 at 5:39 PM, Michael McCandless
> wrote:
>> I can cut the 2.9.1 release, but... should we wait a bit to see
>> whether other issues come up? Or do it, now?
>
> Other issues came up, and were quickly fixed - nice job guys
On Wed, Oct 14, 2009 at 5:39 PM, Michael McCandless
wrote:
> I can cut the 2.9.1 release, but... should we wait a bit to see
> whether other issues come up? Or do it, now?
Other issues came up, and were quickly fixed - nice job guys!.
I don't see anything else serious lurking about... seems like
ah! Thanks Yonik!
-John
On Sun, Oct 18, 2009 at 6:32 AM, Yonik Seeley wrote:
> On Sun, Oct 18, 2009 at 1:43 AM, John Wang wrote:
> > Maybe it is not a big deal. But I would still like to know why in
> > MultiTermDocs, if term is not null, termDocs(term) is not called, rather
> > termDocs() i
On Sun, Oct 18, 2009 at 1:43 AM, John Wang wrote:
> Maybe it is not a big deal. But I would still like to know why in
> MultiTermDocs, if term is not null, termDocs(term) is not called, rather
> termDocs() is.
That would work, but it would sometimes be less efficient.
By calling termDocs() o
On Sun, Oct 18, 2009 at 1:43 AM, John Wang wrote:
> Maybe it is not a big deal. But I would still like to know why in
> MultiTermDocs, if term is not null, termDocs(term) is not called, rather
> termDocs() is.
John are you referring to the protected TermDocs termDocs(IndexReader
reader) metho
Nice :) Fix looks good... I'll commit soon. Thanks!
Mike
On Sat, Oct 17, 2009 at 1:19 PM, Mark Miller wrote:
> Not that I have any comfort with spans - but I'm good with a shovel ;)
>
> Mark Miller wrote:
>> Got it I think.
>>
>> Michael McCandless wrote:
>>
>>> I've marked fix for 2.9.1. Can
Hi guys:
Maybe it is not a big deal. But I would still like to know why in
MultiTermDocs, if term is not null, termDocs(term) is not called, rather
termDocs() is.
Thanks
-John
On Sat, Oct 17, 2009 at 10:16 AM, John Wang wrote:
> Oh ok. I was thinking that if term is not null, termDocs(Term
Not that I have any comfort with spans - but I'm good with a shovel ;)
Mark Miller wrote:
> Got it I think.
>
> Michael McCandless wrote:
>
>> I've marked fix for 2.9.1. Can someone w/ comfort in this (span
>> queries) have a look?
>>
>> If nobody jumps after a while I'll try to dig in...
>>
>
Oh ok. I was thinking that if term is not null, termDocs(Term) would be
called.
-John
On Sat, Oct 17, 2009 at 10:12 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> I think this code is correct? The null is forwarded so SegmentReader
> returns AllDocsEnum.
>
> Mike
>
> On Sat, Oct 17
I think this code is correct? The null is forwarded so SegmentReader
returns AllDocsEnum.
Mike
On Sat, Oct 17, 2009 at 1:09 PM, John Wang wrote:
> In DirectoryReader$MultiTermDocs implementation:
> in method: protected TermDocs termDocs(IndexReader reader)
> return term==null ? reader.termDocs
Got it I think.
Michael McCandless wrote:
> I've marked fix for 2.9.1. Can someone w/ comfort in this (span
> queries) have a look?
>
> If nobody jumps after a while I'll try to dig in...
>
> Mike
>
> On Sat, Oct 17, 2009 at 11:11 AM, Yonik Seeley
> wrote:
>
>> On Wed, Oct 14, 2009 at 5:39 PM
I've marked fix for 2.9.1. Can someone w/ comfort in this (span
queries) have a look?
If nobody jumps after a while I'll try to dig in...
Mike
On Sat, Oct 17, 2009 at 11:11 AM, Yonik Seeley
wrote:
> On Wed, Oct 14, 2009 at 5:39 PM, Michael McCandless
> wrote:
>> I can cut the 2.9.1 release, b
In DirectoryReader$MultiTermDocs implementation:in method: protected
TermDocs termDocs(IndexReader reader)
return term==null ? reader.termDocs(null) : reader.termDocs();
Is this correct?
Shouldn't it be:
return term==null ? reader.termDocs() : reader.termDocs(term);
Thanks
-John
On Sat, Oc
On Wed, Oct 14, 2009 at 5:39 PM, Michael McCandless
wrote:
> I can cut the 2.9.1 release, but... should we wait a bit to see
> whether other issues come up?
I took a quick peek at the test code provided by Peter... and this
certainly looks like a bug:
https://issues.apache.org/jira/browse/LUCENE-
Contrib committers do not have karma for branches - just the trunk
contrib area. I assume its just because of how the karma is granted -
not wildcard based eg */contrib/*.
Michael McCandless wrote:
> Ooh, I'll go commit that one (though it's kinda weird that you're not
> able to do so)...
>
> Any
Ooh, I'll go commit that one (though it's kinda weird that you're not
able to do so)...
Any others?
Mike
On Wed, Oct 14, 2009 at 5:45 PM, Robert Muir wrote:
> can someone take a look at LUCENE-1963? :)
> (there were no objections to back-porting the fix, but i do not have
> permission to do it
Lets cut a release with this scorer bug fix?
On Wed, Oct 14, 2009 at 2:39 PM, Michael McCandless
wrote:
> I can cut the 2.9.1 release, but... should we wait a bit to see
> whether other issues come up? Or do it, now?
>
> If there are any issues you've already fixed on trunk but think should
> al
can someone take a look at LUCENE-1963? :)
(there were no objections to back-porting the fix, but i do not have
permission to do it)
On Wed, Oct 14, 2009 at 5:39 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> I can cut the 2.9.1 release, but... should we wait a bit to see
> whether
34 matches
Mail list logo
