Re: Commit / Code Review Policy

[Bruno Roustant]

I like this new version. This clarifies the review, commit and CHANGES. As
a beginner in this process, it helps.

I appreciate the idea to have a "risk" section where we could list and say
a few words about some risky areas so that the contributor can announce
they might be impacted in reviews.

Le ven. 29 nov. 2019 à 16:06, David Smiley  a
écrit :

> The commit policy / guideline document is basically 95% there and I don't
> want to wait longer to get input.
> https://cwiki.apache.org/confluence/display/LUCENE/Commit+Policy+-+DRAFT
>
> If you log-in, you can comment on the document in-line as Jan has already
> done.  Such feedback is good for details.  For more substantive or high
> level feedback, this email thread probably makes more sense.
>
> The policy/guideline document insists on reviews but gives broad
> exceptions for reviews and defines a very low bar for reviews -- basically
> mere "approval" from *anyone* and that didn't necessarily look at the
> code.  Yet this is a higher bar than today.
>
> Also, I hope this is not controversial but I want the same definition of
> minor/trival matters to be used for (A) when a JIRA issue is not needed
> either, and (B) not bothering with a CHANGES.txt entry.  I observe that
> today we seemingly have a JIRA issue for *everything*, and I find that
> onerous and is yet another barrier for contributors of such small matters.
> For example https://issues.apache.org/jira/browse/SOLR-13926 which just
> adds javadocs.  Also I think we add too many items to CHANGES.txt... lots
> of people read this and it's a collective waste of our time IMO to mention
> that some test was fixed.
>
> All feedback is very welcome!
>
> ~ David
>

Re: [VOTE] Release Lucene/Solr 8.3.1 RC2

[MUNENDRA S N]

+1

SUCCESS! [1:28:14.138771]



On Fri, Nov 29, 2019 at 8:12 PM Jan Høydahl  wrote:

> +1
>
> SUCCESS! [1:52:34.599842]
>
> I still think https://issues.apache.org/jira/browse/SOLR-13977 is
> important and should be mentioned in release email.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 29. nov. 2019 kl. 10:07 skrev Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com>:
>
> Please vote for release candidate 2 for Lucene/Solr 8.3.1
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>
> The vote will be open for at least 72 hours from now.
>
> [x] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

Re: Commit / Code Review Policy

[David Smiley]

The commit policy / guideline document is basically 95% there and I don't
want to wait longer to get input.
https://cwiki.apache.org/confluence/display/LUCENE/Commit+Policy+-+DRAFT

If you log-in, you can comment on the document in-line as Jan has already
done.  Such feedback is good for details.  For more substantive or high
level feedback, this email thread probably makes more sense.

The policy/guideline document insists on reviews but gives broad exceptions
for reviews and defines a very low bar for reviews -- basically mere
"approval" from *anyone* and that didn't necessarily look at the code.  Yet
this is a higher bar than today.

Also, I hope this is not controversial but I want the same definition of
minor/trival matters to be used for (A) when a JIRA issue is not needed
either, and (B) not bothering with a CHANGES.txt entry.  I observe that
today we seemingly have a JIRA issue for *everything*, and I find that
onerous and is yet another barrier for contributors of such small matters.
For example https://issues.apache.org/jira/browse/SOLR-13926 which just
adds javadocs.  Also I think we add too many items to CHANGES.txt... lots
of people read this and it's a collective waste of our time IMO to mention
that some test was fixed.

All feedback is very welcome!

~ David

Re: [VOTE] Release Lucene/Solr 8.3.1 RC2

[Jan Høydahl]

+1

SUCCESS! [1:52:34.599842]

I still think https://issues.apache.org/jira/browse/SOLR-13977 
 is important and should be 
mentioned in release email.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 29. nov. 2019 kl. 10:07 skrev Ishan Chattopadhyaya 
> :
> 
> Please vote for release candidate 2 for Lucene/Solr 8.3.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
> 
> The vote will be open for at least 72 hours from now.
> 
> [x] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: [VOTE] Release Lucene/Solr 8.3.1 RC2

[Shalin Shekhar Mangar]

+1

SUCCESS! [0:49:22.229435]

On Fri, Nov 29, 2019 at 2:38 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Please vote for release candidate 2 for Lucene/Solr 8.3.1
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>
> The vote will be open for at least 72 hours from now.
>
> [x] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Regards,
Shalin Shekhar Mangar.

Lucene Upgrade issues.

[Jyothsna Bavisetti]

Hi All,

We are upgrading Lucene from 4.6 to 8.3. 

In latest version, we are extending BaseDirectory class. In that rename method 
is called for copying latest segment data, while committing index data. 

Files.move(src,dst, new CopyOption[] { StandardCopyOption.ATOMIC_MOVE });

I am trying to use above line for copying, but it is looping at this rename 
method. Can you please share some inputs
Please share some inputs. 
Lucene Serach is failing with below error:

Search Execution Error: no segments* file found in Directory@68cbb8b9 
lockFactory=oracle.edq.clustering.coherence.lucene.Locker@74688f8b: files: [] 
(Code: 300,138)
at 

Please share some inputs to trace this issue.

Thanks,
Jyothsna

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: DelimitedTermFrequencyTokenFilter

[Edward Ribeiro]

Oh, silly of me. :)

Thanks,
Edward

Em sex, 29 de nov de 2019 07:13, Alan Woodward 
escreveu:

> I think it’s working fine - Luke is showing you the docFreq of the term,
> which will be 1 as it only appears in a single document.
>
> On 28 Nov 2019, at 21:51, Edward Ribeiro  wrote:
>
> Hi,
>
> Please, anyone has an example of DelimitedTermFrequencyTokenFilter use
> that could share?
>
> I have been banging my head against the wall trying to make it work (
> https://gist.github.com/eribeiro/ebb24feb3fd84931b7c288b9b716ed49 ) and
> idk what I am doing wrong.
>
> I am creating a custom analyzer that uses a WhitespaceTokenizer to parse a
> string like "a|10 b|2 c|9", and pass it to
> DelimitedTermFrequencyTokenFilter. I am inserting a custom field that is
> added to the document to prevent it from having positions and offsets.
>
> The debugger shows the string is being correctly parsed by DTFTF and its
> char and term attributes are properly set up. But the term frequency of
> each term is 1 when I inspect the index via Luke. Curiously, the output of
> my snippet shows the correct total term frequency as seen below:
>
> field="text",maxDoc=1,docCount=1,sumTotalTermFreq=123,sumDocFreq=3
> a|10 b|23 c|90
> SumTotalTermFreq: 123
> SumDocFreq: 3
>
> Cheers,
> Edward
> PS: I am a Lucene newbie so it may be something quite stupid.
>
>
>

Re: DelimitedTermFrequencyTokenFilter

[Alan Woodward]

I think it’s working fine - Luke is showing you the docFreq of the term, which 
will be 1 as it only appears in a single document.

> On 28 Nov 2019, at 21:51, Edward Ribeiro  > wrote:
> 
> Hi,
> 
> Please, anyone has an example of DelimitedTermFrequencyTokenFilter use that 
> could share? 
> 
> I have been banging my head against the wall trying to make it work ( 
> https://gist.github.com/eribeiro/ebb24feb3fd84931b7c288b9b716ed49 
>  ) and idk 
> what I am doing wrong. 
> 
> I am creating a custom analyzer that uses a WhitespaceTokenizer to parse a 
> string like "a|10 b|2 c|9", and pass it to DelimitedTermFrequencyTokenFilter. 
> I am inserting a custom field that is added to the document to prevent it 
> from having positions and offsets.
> 
> The debugger shows the string is being correctly parsed by DTFTF and its char 
> and term attributes are properly set up. But the term frequency of each term 
> is 1 when I inspect the index via Luke. Curiously, the output of my snippet 
> shows the correct total term frequency as seen below:
> 
> field="text",maxDoc=1,docCount=1,sumTotalTermFreq=123,sumDocFreq=3
> a|10 b|23 c|90
> SumTotalTermFreq: 123
> SumDocFreq: 3
> 
> Cheers,
> Edward
> PS: I am a Lucene newbie so it may be something quite stupid. 
> 

JDK 14 - Early Access build 25 is available

[Rory O'Donnell]

Hi Uwe & Dawid,

*OpenJDK builds  - JDK 14 *- Early Access build 25 is available at 
http://jdk.java.net/14/


These early-access, open-source builds are provided under the GNU 
General Public License, version 2, with the Classpath Exception 
.


 * *Next Milestone*
   **
 o ** *12-Dec-2019 Rampdown Phase One.*

 * Release notes
 o https://jdk.java.net/14/release-notes
 * JEP proposed to target JDK 14
 o JEP 365 ZGC on Windows 
 * JEPs targeted to JDK 14, so far:
 o JEP 305: Pattern Matching for instanceof (Preview)
    was proposed to target.
 o JEP 343: Packaging Tool (Incubator)
    was proposed to target.
 o JEP 345: NUMA-Aware Memory Allocation for G1
    was integrated.
 o JEP 349: JFR Event Streaming
    was integrated.
 o JEP 352: Non-Volatile Mapped Byte Buffers
    was targeted.
 o JEP 358: Helpful NullPointerExceptions
    was integrated.
 o JEP 359: Records (Preview) 
   JEP 359: Records (Preview)
    was proposed to target.
 o JEP 361: Switch Expressions (Standard)
    was intergrated.
 o JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
   Collector  was targeted.
 o JEP 364: ZGC on macOS  was
   targeted.
 o JEP 366: Deprecate the ParallelScavenge + SerialOld GC
   Combination  was proposed to
   target.
 o JEP 367: Remove the Pack200 Tools and API
    was targeted to JDK 14.
 o JEP 368: Text Blocks (Second Preview)
    was proposed to target.

 * Recent Bug fixes of Interest

 * Build 25:
 o JDK-8233301: Implementation of JEP 366: Deprecate the
   ParallelScavenge + SerialOld GC Combination
 o JDK-8233296: The behavior of MulticastSocket
   getOption/setOption for IP_MULTICAST_LOOP is changed to
   conform the specification of
   StandardSocketOptions.IP_MULTICAST_LOOP
 * Build 24:
 o JDK-8233141 :DatagramSocket.send and MulticastSocket.send
   throw IllegalArgumentException when the socket is not
   connected and the packet doesn't contain any address )
 o JDK-8214024: Remove the default keytool -keyalg value
 o JDK-8232019: Add LuxTrust certificate updates to the
   existing root program
 * Build 23
 o JDK 8232365: Implementation for JEP 363: Remove the
   Concurrent Mark Sweep (CMS) Garbage Collector
 o JDK 8224817: Implementation of JEP 364: ZGC on macOS

 * Changes in this build
   


*jpackage EA -* Build 14-jpackage+1-70 (2019/11/12)

 * This is an early access build of JEP 343: Packaging Tool
   , aimed at testing a prototype
   implementation of jpackage, which is a new tool for packaging
   self-contained Java applications along with a Java Runtime Environment.
 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   
 * Build is now available http://jdk.java.net/jpackage/
 * Please send feedback via e-mail to core-libs-...@openjdk.java.net
   

Rgds,Rory**
**

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

[VOTE] Release Lucene/Solr 8.3.1 RC2

[Ishan Chattopadhyaya]

Please vote for release candidate 2 for Lucene/Solr 8.3.1

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f

You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f

The vote will be open for at least 72 hours from now.

[x] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org