Thanks for putting this together, Ishan! On Mon, Jun 5, 2017 at 1:05 PM, Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote:
> Hi all, > I've updated the release notes here: > https://wiki.apache.org/lucene-java/ReleaseNote66 > https://wiki.apache.org/solr/ReleaseNote66 > > Please review / feel free to edit. > I have started the maven sync, so we have about 24 hours (for maven sync) > until I update these to the website and announce the release. > Thanks and regards, > Ishan > > On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jpou...@gmail.com> wrote: > >> Sorry to hear that, make sure to take care of yourself first, the release >> can wait! I just backported to branch_6_6. >> >> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> a écrit : >> >>> Hi Adrien, >>> Please proceed, by all means, to backport to release branch. I'm unwell >>> today, and I haven't been able to start the RC cutting today; planning to >>> do so after another 5-6 hours' rest. >>> Thanks, >>> Ishan >>> >>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jpou...@gmail.com> >>> wrote: >>> >>>> Hi Ishan, >>>> >>>> I don't think it is worth restarting RC build in case you already >>>> started, but in case you haven't started yet, >>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to >>>> have in 6.6. >>>> >>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya < >>>> ichattopadhy...@gmail.com> a écrit : >>>> >>>>> I attempted to build an RC, but failed repeatedly before realizing it >>>>> was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've >>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, >>>>> as >>>>> I'm about to wrap up the day's work. >>>>> >>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya < >>>>> ichattopadhy...@gmail.com> wrote: >>>>> >>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the release >>>>>> branch. It affects only the feature introduced in SOLR-8440. Please let >>>>>> me >>>>>> know if someone has any objections. >>>>>> >>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let >>>>>> me know if there's something that someone is working on which needs to >>>>>> get >>>>>> in before that. >>>>>> >>>>>> Thanks and regards, >>>>>> Ishan >>>>>> >>>>>> >>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya < >>>>>> ichattopadhy...@gmail.com> wrote: >>>>>> >>>>>>> Sure Steve! Thanks! >>>>>>> >>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sar...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Ishan, >>>>>>>> >>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 >>>>>>>> for 6.6? >>>>>>>> >>>>>>>> -- >>>>>>>> Steve >>>>>>>> www.lucidworks.com >>>>>>>> >>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi < >>>>>>>> jim.feren...@gmail.com> wrote: >>>>>>>> > >>>>>>>> > Ok thanks Ishan. >>>>>>>> > >>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" < >>>>>>>> ichattopadhy...@gmail.com> a écrit : >>>>>>>> > Sure, Jim. Please go ahead! >>>>>>>> > >>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi < >>>>>>>> jim.feren...@gmail.com> wrote: >>>>>>>> > Hi, >>>>>>>> > Would be great to have https://issues.apache.org/jira >>>>>>>> /browse/LUCENE-7824 included for 6.6. Can I merge the fix this >>>>>>>> week end Ishan ? >>>>>>>> > >>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya < >>>>>>>> ichattopadhy...@gmail.com>: >>>>>>>> > Done, Adrien. Thanks! >>>>>>>> > >>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jpou...@gmail.com> >>>>>>>> wrote: >>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as >>>>>>>> well? I think it would help realize that the 6.6 branch has been cut >>>>>>>> when >>>>>>>> looking at the CHANGES.txt file and not forget about backporting? >>>>>>>> > >>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya < >>>>>>>> ichattopadhy...@gmail.com> a écrit : >>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to >>>>>>>> add bugfixes to the branch, if needed. >>>>>>>> > Planning to build the first RC on 15 May. Please let me know if >>>>>>>> there are any objections. >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > Ishan >>>>>>>> > >>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya < >>>>>>>> ichattopadhy...@gmail.com> wrote: >>>>>>>> > Planning to cut the release branch in another 10-12 hours. >>>>>>>> > >>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty < >>>>>>>> mgai...@hotmail.com> wrote: >>>>>>>> > i was wondering if there was a specific test for >>>>>>>> SpanPayloadCheckQuery method >>>>>>>> > >>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload); >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > the only implementation i could locate was in collectLeaf of >>>>>>>> SpanPayloadCheckQuery >>>>>>>> > >>>>>>>> > >>>>>>>> > I will submit JIRA with Patch >>>>>>>> > >>>>>>>> > >>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting >>>>>>>> sentence fragments (what we called phenomes) than current SEO >>>>>>>> implementations >>>>>>>> > >>>>>>>> > >>>>>>>> > Can you suggest a book to read to better understand Lucenes >>>>>>>> pattern dissection and match algorithms? >>>>>>>> > >>>>>>>> > >>>>>>>> > Many Thanks for helpful guidance >>>>>>>> > Martin >>>>>>>> > ______________________________________________ >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > From: Erik Hatcher <erik.hatc...@gmail.com> >>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM >>>>>>>> > >>>>>>>> > To: dev@lucene.apache.org >>>>>>>> > Subject: Re: Release 6.6 >>>>>>>> > >>>>>>>> > Martin - >>>>>>>> > >>>>>>>> > I have to admit to still being unsure what the gist is here - is >>>>>>>> there a bug? Apologies for not catching what you’re saying/showing >>>>>>>> here. >>>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as >>>>>>>> expected >>>>>>>> now. >>>>>>>> > >>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it >>>>>>>> committed for 6.6. If there is an issue to address with your work >>>>>>>> would >>>>>>>> you please open a JIRA and include your patch there? >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > Erik >>>>>>>> > >>>>>>>> > >>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mgai...@hotmail.com> >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> Mornin' Erik >>>>>>>> >> >>>>>>>> >> there is a collectLeaf override in >>>>>>>> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its >>>>>>>> never called: >>>>>>>> >> >>>>>>>> >> static class VerifyingCollector implements SpanCollector { >>>>>>>> >> List<BytesRef> payloads = new ArrayList<>(); >>>>>>>> >> @Override >>>>>>>> >> public void collectLeaf(PostingsEnum postings, int position, >>>>>>>> Term term) throws IOException { >>>>>>>> >> .... >>>>>>>> >> } >>>>>>>> >> } >>>>>>>> >> >>>>>>>> >> the modification in >>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadCheckQuery >>>>>>>> tests collectLeaf for query >>>>>>>> >> >>>>>>>> >> //initialise term >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 >>>>>>>> before term1=new org.apache.lucene.index.Term(' >>>>>>>> field','withPayload')"); >>>>>>>> >> org.apache.lucene.index.Term term1=new >>>>>>>> org.apache.lucene.index.Term("field", "withPayload"); >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233 >>>>>>>> term1="+term1); >>>>>>>> >> >>>>>>>> >> //assume position is 5 >>>>>>>> >> int position=5; >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 235 position="+position); >>>>>>>> >> >>>>>>>> >> BytesRef pay = new BytesRef("pos: " + position); >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 237 pay="+pay); >>>>>>>> >> >>>>>>>> >> //build spanQuery with term parameter >>>>>>>> >> org.apache.lucene.search.spans.SpanQuery spanQuery1 = new >>>>>>>> SpanTermQuery(term1); >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 239 spanQuery1="+spanQuery1); >>>>>>>> >> >>>>>>>> >> //add BytesRef to payloadToMatch list >>>>>>>> >> java.util.List<org.apache.lucene.util.BytesRef> >>>>>>>> payloadToMatch=new java.util.ArrayList<org.apache >>>>>>>> .lucene.util.BytesRef>(); >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 241 payloadToMatch="+payloadToMatch); >>>>>>>> >> payloadToMatch.add(pay); >>>>>>>> >> >>>>>>>> >> //build SpanPayloadCheckQuery >>>>>>>> >> query=new org.apache.lucene.queries.payl >>>>>>>> oads.SpanPayloadCheckQuery( >>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query, >>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMa >>>>>>>> tch); >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249 >>>>>>>> query="+query); >>>>>>>> >> >>>>>>>> >> //build lucene Directory (TODO: we should use an existing >>>>>>>> directory with REAL test-data) >>>>>>>> >> org.apache.lucene.store.Directory ram = >>>>>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedCo >>>>>>>> ntext.current().getRandom()); >>>>>>>> >> >>>>>>>> >> //build SegmentReader from Directory >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251 >>>>>>>> ram="+ram); >>>>>>>> >> SegmentReader reader = getOnlySegmentReader(org.apach >>>>>>>> e.lucene.index.DirectoryReader.open(ram)); >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253 >>>>>>>> reader="+reader); >>>>>>>> >> >>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader >>>>>>>> >> org.apache.lucene.index.LeafReader sr = >>>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader); >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 255 sr="+sr); >>>>>>>> >> >>>>>>>> >> //add term to SegmentReader postings >>>>>>>> >> org.apache.lucene.index.PostingsEnum postings = >>>>>>>> sr.postings(term1, PostingsEnum.PAYLOADS); >>>>>>>> >> >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 >>>>>>>> before >>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where >>>>>>>> postings="+postings); >>>>>>>> >> >>>>>>>> >> //display the parameters for collectLeaf method for query: >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 >>>>>>>> before >>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where >>>>>>>> position="+position); >>>>>>>> >> >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 >>>>>>>> before >>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where >>>>>>>> term1="+term1); >>>>>>>> >> try >>>>>>>> >> { //public void collectLeaf(org.apache.lucene.index.PostingsEnum >>>>>>>> postings, int position, //org.apache.lucene.index.Term term) >>>>>>>> throws java.io.IOException { >>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1); >>>>>>>> >> } >>>>>>>> >> catch(java.io.IOException ioe) { >>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck >>>>>>>> LINE 264 >>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws >>>>>>>> IOException ="+ioe.getMessage()); } >>>>>>>> >> >>>>>>>> >> collectLeaf is the only method that compares >>>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload) >>>>>>>> >> to determine "match" >>>>>>>> >> >>>>>>>> >> unless of course match between individual payload and >>>>>>>> payloadToMatch is tested elsewhere ? >>>>>>>> >> >>>>>>>> >> WDYT? >>>>>>>> >> Martin >>>>>>>> >> ______________________________________________ >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> From: Erik Hatcher <erik.hatc...@gmail.com> >>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM >>>>>>>> >> To: Lucene/Solr dev >>>>>>>> >> Subject: Re: Release 6.6 >>>>>>>> >> >>>>>>>> >> Martin - >>>>>>>> >> >>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out >>>>>>>> as it uses some logging and APIs that aren’t already in the project and >>>>>>>> classpath of these lucene tests within that queries module (within >>>>>>>> IntelliJ, mind you). >>>>>>>> >> >>>>>>>> >> I was able to resolve the misunderstanding (and >>>>>>>> .equals/.hashCode bugs) so everything is working as expected with >>>>>>>> SpanPayloadCheckQuery for me now. Do your tests point out an issue? >>>>>>>> Or >>>>>>>> confirming that it is working properly at a lower level? >>>>>>>> >> >>>>>>>> >> Erik >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mgai...@hotmail.com> >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it, >>>>>>>> click the link below. >>>>>>>> >>> >>>>>>>> >>> TestPayloadCheckQuery.java >>>>>>>> >>> attached >>>>>>>> >>> >>>>>>>> >>> I coded this last nite so it is "quick and dirty" >>>>>>>> >>> >>>>>>>> >>> in any case let me know if testSpanPayloadCheck() method >>>>>>>> modification properly addresses your situation >>>>>>>> >>> >>>>>>>> >>> Thanks! >>>>>>>> >>> Martin >>>>>>>> >>> ______________________________________________ >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> From: Erik Hatcher <erik.hatc...@gmail.com> >>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM >>>>>>>> >>> To: dev@lucene.apache.org >>>>>>>> >>> Subject: Re: Release 6.6 >>>>>>>> >>> >>>>>>>> >>> Martin - there is a test class specifically for this query. >>>>>>>> See the recent commits I've made to test it further fixing >>>>>>>> .equals/.hashCode and rewrite. >>>>>>>> >>> >>>>>>>> >>> Can you send your full test code? >>>>>>>> >>> >>>>>>>> >>> Erik >>>>>>>> >>> >>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mgai...@hotmail.com> >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to >>>>>>>> work I was about to reply just run that TestCase >>>>>>>> >>>> (until i discovered there wasnt any!) >>>>>>>> >>>> >>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase >>>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod: >>>>>>>> >>>> @org.junit.Test >>>>>>>> >>>> public void testSpanPayloadCheck() throws Exception >>>>>>>> >>>> >>>>>>>> >>>> //now lets test the collectLeaf for query >>>>>>>> >>>> //of course calling Base Class SpanPayloadCheckQuery to >>>>>>>> construct query >>>>>>>> >>>> >>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 257 before query.getPayloadChecker().coll >>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where >>>>>>>> postings="+postings); >>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 258 before query.getPayloadChecker().coll >>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where >>>>>>>> position="+position); >>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE >>>>>>>> 259 before query.getPayloadChecker().coll >>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where >>>>>>>> term1="+term1); >>>>>>>> >>>> >>>>>>>> >>>> try >>>>>>>> >>>> { //test public void >>>>>>>> >>>> collectLeaf(org.apache.lucene.index.PostingsEnum >>>>>>>> postings, int position, //org.apache.lucene.index.Term >>>>>>>> term) >>>>>>>> throws java.io.IOException { >>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1); >>>>>>>> >>>> } >>>>>>>> >>>> catch(java.io.IOException ioe) { >>>>>>>> >>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck >>>>>>>> LINE 264 >>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, >>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws >>>>>>>> IOException ="+ioe.getMessage()); } >>>>>>>> >>>> >>>>>>>> >>>> unless of course anyone has a better idea to test collectLeaf ? >>>>>>>> >>>> Martin >>>>>>>> >>>> ______________________________________________ >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> From: Erik Hatcher <erik.hatc...@gmail.com> >>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM >>>>>>>> >>>> To: dev@lucene.apache.org >>>>>>>> >>>> Subject: Re: Release 6.6 >>>>>>>> >>>> >>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a good >>>>>>>> start (or will the 2.5 year old patch still apply and be acceptable >>>>>>>> as-is?) >>>>>>>> >>>> >>>>>>>> >>>> Erik >>>>>>>> >>>> >>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood < >>>>>>>> wun...@wunderwood.org> wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included? >>>>>>>> >>>>> >>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629 >>>>>>>> >>>>> >>>>>>>> >>>>> wunder >>>>>>>> >>>>> Walter Underwood >>>>>>>> >>>>> wun...@wunderwood.org >>>>>>>> >>>>> http://observer.wunderwood.org/ (my blog) >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya < >>>>>>>> ichattopadhy...@gmail.com> wrote: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Hi, >>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6. >>>>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix >>>>>>>> release >>>>>>>> before 7.0 release). >>>>>>>> >>>>>> >>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release >>>>>>>> branch around 4th May, in order to let some time for devs to finish >>>>>>>> current >>>>>>>> issues. >>>>>>>> >>>>>> >>>>>>>> >>>>>> What do you think? >>>>>>>> >>>>>> >>>>>>>> >>>>>> Regards, >>>>>>>> >>>>>> Ishan >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>>>> --------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >
