RE: BugFix release 7.2.1

http://www.thetaphi.de eMail: u...@thetaphi.de *From:* jim ferenczi [mailto:jim.feren...@gmail.com] *Sent:* Tuesday, January 9, 2018 11:00 AM *To:* dev@lucene.apache.org *Subject:* Re: BugFix release 7.2.1 Hi, All the issues we discussed have been backported to 6.2. I added the draft for

RE: BugFix release 7.2.1

:00 AM To: dev@lucene.apache.org Subject: Re: BugFix release 7.2.1 Hi, All the issues we discussed have been backported to 6.2. I added the draft for the release notes in the wiki: https://wiki.apache.org/lucene-java/ReleaseNote721 https://wiki.apache.org/solr/ReleaseNote721 I'll

Re: BugFix release 7.2.1

Hi, All the issues we discussed have been backported to 6.2. I added the draft for the release notes in the wiki: https://wiki.apache.org/lucene-java/ReleaseNote721 https://wiki.apache.org/solr/ReleaseNote721 I'll create the first RC later today. 2018-01-09 4:56 GMT+01:00 S G : > Sorry, I miss

Re: BugFix release 7.2.1

Sorry, I missed some of the details but this is what we did in one of my past projects with success: We can begin by supporting only those machines where Apache Solr's regression tests are run. The aim is to identify OS-independent performance regressions, not to certify each OS where Solr could b

Re: BugFix release 7.2.1

Hmmm, I think you missed my implied point. How are these metrics collected and compared? There are about a dozen different machines running various op systems etc. For these measurements to spot regressions and/or improvements, they need to have a repository where the results get published. So a re

Re: BugFix release 7.2.1

We can put some lower limits on CPU and Memory for running a performance test. If those lower limits are not met, then the test will just skip execution. And then we put some lower bounds (time-wise) on the time spent by different parts of the test like: - Max time taken to index 1 million docume

Re: BugFix release 7.2.1

Erick, I'll merge SOLR-11783 and SOLR-11555 in the 7.2 branch. Though I am waiting for SOLR-11771 and https://issues.apache.org/jira/browse/SOLR-11809 to be resolved and I'll create a candidate for the release. Cheers, Jim 2018-01-06 18:59 GMT+

Re: BugFix release 7.2.1

Not sure how performance tests in the unit tests would be interpreted. If I run the same suite on two different machines how do I compare the numbers? Or are you thinking of having some tests so someone can check out different versions of Solr and run the perf tests on a single machine, perhaps us

Re: BugFix release 7.2.1

Just curious to know, does the test suite include some performance test also? I would like to know the performance impact of using pints vs tints or ints etc. If they are not there, I can try to add some tests for the same. Thanks SG On Fri, Jan 5, 2018 at 5:47 PM, Đạt Cao Mạnh wrote: > Hi all

Re: BugFix release 7.2.1

Hi all, I will work on SOLR-11771 today, It is a simple fix and will be great if it get fixed in 7.2.1 On Fri, Jan 5, 2018 at 11:23 PM Erick Erickson wrote: > Neither of those Solr fixes are earth shatteringly important, they've both > been aro

Re: BugFix release 7.2.1

Neither of those Solr fixes are earth shatteringly important, they've both been around for quite a while. I don't think it's urgent to include them. That said, they're pretty simple and isolated so worth doing if Jim is willing. But not worth straining much. I was just clearing out some backlog ov

Re: BugFix release 7.2.1

https://issues.apache.org/jira/browse/SOLR-11809 is in progress, should be easy and I think definitely worth backporting On Fri, Jan 5, 2018 at 8:52 AM Adrien Grand wrote: > +1 > > Looking at the changelog, 7.3 has 3 bug fixes for now: LUCENE-8077, > SOLR-11783 and SOLR-11555. The Lucene change

Re: BugFix release 7.2.1

+1 Looking at the changelog, 7.3 has 3 bug fixes for now: LUCENE-8077, SOLR-11783 and SOLR-11555. The Lucene change doesn't seem worth backporting, but maybe the Solr changes should? Le ven. 5 janv. 2018 à 12:40, jim ferenczi a écrit : > Hi, > We discovered a bad bug in 7x that affects indices

BugFix release 7.2.1

Hi, We discovered a bad bug in 7x that affects indices created in 6x with Lucene54DocValues format. The SortedNumericDocValues created with this format have a bug when advanceExact is used, the values retrieved for the docs when advanceExact returns true are invalid (the pointer to the values is no