[no subject]

[no subject]

Hello to all users, contributors and Committers! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code EU 2024 are now open! We will be supporting Community over Code EU, Bratislava, Slovakia, June 3th - 5th, 2024. TAC exists

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Looks like a fair deal. I will check daily for the release to appear. Once all looks fine I will update the PR and change away from draft status. Uwe Am 21.09.2022 um 20:44 schrieb Michael Sokolov: OK, how does this sound: if there is a (JDK19 AdoptOpenJDK) release this week as it seems there

Re: Subject: New branch and feature freeze for Lucene 9.4.0

OK, how does this sound: if there is a (JDK19 AdoptOpenJDK) release this week as it seems there should be, and you are able to fast-follow with the Lucene changes to use it then I can re-spin RC2 on Monday or Tuesday. On Wed, Sep 21, 2022 at 1:35 PM Uwe Schindler wrote: > > FYI, here

Re: Subject: New branch and feature freeze for Lucene 9.4.0

FYI, here (https://github.com/adoptium/adoptium/issues/171) Eclipse says: * Add website banner (automate* via github workflow in website repository) - Announce that we target releases to be available within 48-72 hours of the GA tags being available Uwe Am 21.09.2022 um 14:31 schrieb Uwe

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hi, I will check later today how long it took last time in March. I would have expected that they just need to wait until the builds and tests are done so it gets released. I don't want to hold up the release. The vote is still ongoning, so we have all options. Uwe Am 21.09.2022 um 14:05

Re: Subject: New branch and feature freeze for Lucene 9.4.0

I see; I would kind of like to get the release out before ApacheCon NA, which starts Oct 3. Do you think it's likely AdoptOpenJDK will release its JDK19 in the next week (say by Sep 26)? On Wed, Sep 21, 2022 at 4:32 AM Uwe Schindler wrote: > > Hi, > > JDK 19 was released yesterday and I am still

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hi, JDK 19 was released yesterday and I am still waiting for AdoptOpenJDK to publish Gradle Toolchain compatible releases to be available. To me the schedule is a bit bad: Just on the day of the possibility to add (optional) support for JDK 19 Panama powered MMAP, we started the release. I

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Both changes are on branch_9_4 now. On Tue, Sep 20, 2022 at 1:31 PM Michael Sokolov wrote: > well, I did start, optimistically, but I think I need to re-spin to > include a fix for this test failure that has been popping up, so I will > pull these in too. > > On Tue, Sep 20, 2022 at 6:24 AM

Re: Subject: New branch and feature freeze for Lucene 9.4.0

well, I did start, optimistically, but I think I need to re-spin to include a fix for this test failure that has been popping up, so I will pull these in too. On Tue, Sep 20, 2022 at 6:24 AM Adrien Grand wrote: > Hi Mike, > > If you have not started a RC yet, I'd like to include some small

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hi Mike, If you have not started a RC yet, I'd like to include some small fixes for bugs that were recently introduced in Lucene: - https://github.com/apache/lucene/pull/11792 - https://github.com/apache/lucene/pull/11794 On Tue, Sep 20, 2022 at 1:26 AM Julie Tibshirani wrote: > Sorry for

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Sorry for the confusion. To explain, I use a local ann-benchmarks set-up that makes use of KnnGraphTester. It is a bit hacky and I accidentally included the warm-ups in the final timings. So the change to warm-up explains why we saw different results in our tests. This is great motivation to

Re: Subject: New branch and feature freeze for Lucene 9.4.0

I'm confused, since warming should not be counted in the timings. Are you saying that the recall was affected?? On Mon, Sep 19, 2022 at 6:12 PM Julie Tibshirani wrote: > Using the ann-benchmarks framework, I still saw a similar regression as > Mayya between 9.3 and 9.4. I investigated and found

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Using the ann-benchmarks framework, I still saw a similar regression as Mayya between 9.3 and 9.4. I investigated and found it was due to "KnnGraphTester to use KnnVectorQuery" ( https://github.com/apache/lucene/pull/796), specifically the change to the warm-up strategy. If I revert it, the

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Thanks for your speedy testing! I am observing comparable latencies *when the index geometry (ie number of segments)* is unchanged. Agree we can leave this for a later day. I'll proceed to cut 9.4 artifacts On Mon, Sep 19, 2022 at 11:02 AM Mayya Sharipova wrote: > It would be great if you all

Re: Subject: New branch and feature freeze for Lucene 9.4.0

> > It would be great if you all are able to test again with > https://github.com/apache/lucene/pull/11781/ applied I ran the ann benchmarks with this change, and was happy to confirm that in my test recall with this PR is the same as in 9.3 branch, although QPS is lower, but we can

Re: Subject: New branch and feature freeze for Lucene 9.4.0

OK, I think I was wrong about latency having increased due to a change in KnnGraphTester -- I did some testing there and couldn't reproduce. There does seem to be a slight vector search latency increase, possibly noise, but maybe due to the branching introduced to check whether to do byte vs float

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Thanks for the deep-dive Julie. I was able to reproduce the changing recall. I had introduced some bugs in the diversity checks (that may have partially canceled each other out? it's hard to understand what was happening in the buggy case) and posted a fix today

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Thank you Mike, I just backported the change. On Thu, Sep 15, 2022 at 6:32 PM Michael Sokolov wrote: > it looks like a small bug fix, we have had on main (and 9.x?) for a > while now and no test failures showed up, I guess. Should be OK to > port. I plan to cut artifacts this weekend, or Monday

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hello! I also ran some local vector search benchmarks on branch_9_4. I found that given the same parameters, there is a significant change in recall/ QPS before and after the initial "enable quantization to 8-bit" backport (https://github.com/apache/lucene/pull/1054). Here's an example with M=16,

Re: Subject: New branch and feature freeze for Lucene 9.4.0

it looks like a small bug fix, we have had on main (and 9.x?) for a while now and no test failures showed up, I guess. Should be OK to port. I plan to cut artifacts this weekend, or Monday at the latest, but if you can do the backport today or tomorrow, that's fine by me. On Thu, Sep 15, 2022 at

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Mike, I'm tempted to backport https://github.com/apache/lucene/pull/1068 to branch_9_4, which is a bugfix that looks pretty safe to me. What do you think? On Tue, Sep 13, 2022 at 4:11 PM Mayya Sharipova wrote: > Thanks for running more tests, Michael. > It is encouraging that you saw a similar

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Thanks for running more tests, Michael. It is encouraging that you saw a similar performance between 9.3 and 9.4. I will also run more tests with different parameters. On Tue, Sep 13, 2022 at 9:30 AM Michael Sokolov wrote: > As a follow-up, I ran a test using the same parameters as above, only

Re: Subject: New branch and feature freeze for Lucene 9.4.0

As a follow-up, I ran a test using the same parameters as above, only changing M=200 to M=16. This did result in a single segment in both cases (9.3, 9.4) and the performance was pretty similar; within noise I think. The main difference I saw was that the 9.3 index was written using CFS: 9.4:

Re: Subject: New branch and feature freeze for Lucene 9.4.0

I ran another test. I thought I had increased the RAM buffer size to 8G and heap to 16G. However I still see two segments in the index that was created. And looking at the infostream I see: dir=MMapDirectory@/local/home/sokolovm/workspace/knn-perf/glove-100-angular.hdf5-train-200-200.index

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hi Mayya, thanks for persisting - I think we need to wrestle this to the ground for sure. In the test I ran, RAM buffer was the default checked in, which is weirdly: 1994MB. I did not specifically set heap size. I used maxConn/M=200. I'll try with larger buffer to see if I can get 9.4 to produce

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hello Michael, Thanks for checking. Sorry for bringing this up again. First of all, I am ok with proceeding with the Lucene 9.4 release and leaving the performance investigations for later. I am interested in what's the maxConn/M value you used for your tests? What was the heap memory and the

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Done. Thanks! > On 9 Sep 2022, at 16:32, Michael Sokolov wrote: > > Hi Alan - I checked out the interval queries patch; seems pretty safe, > please go ahead and port to 9.4. Thanks! > > Mike > > On Fri, Sep 9, 2022 at 10:41 AM Alan Woodward wrote: >> >> Hi Mike, >> >> I’ve opened

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hi Alan - I checked out the interval queries patch; seems pretty safe, please go ahead and port to 9.4. Thanks! Mike On Fri, Sep 9, 2022 at 10:41 AM Alan Woodward wrote: > > Hi Mike, > > I’ve opened https://github.com/apache/lucene/pull/11760 as a small bug fix PR > for a problem with

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hi Mike, I’ve opened https://github.com/apache/lucene/pull/11760 as a small bug fix PR for a problem with interval queries. Am I OK to port this to the 9.4 branch? Thanks, Alan > On 2 Sep 2022, at 20:42, Michael Sokolov

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Thanks Julie, I looked and left some minor comments. Let's target that searchNearestVectors refactor for 9.4.0. As for removing the generics, it would be great if we can further simplify, but agree it doesn't seem critical to target this release, although if we can get it pushed by next week that

Re: Subject: New branch and feature freeze for Lucene 9.4.0

Hi Mike, I've been working on follow-up refactors to the vector encoding work we just added in 9.4 (https://github.com/apache/lucene/pull/1054) and had a couple things to check with you. First, I opened a PR to remove LeafReader#searchNearestVectorsExhaustively (

Re: Subject: New branch and feature freeze for Lucene 9.4.0

> Branch branch_9_4 has been cut and versions updated to 9.5 on stable branch. Then the GitHub Milestone for 9.5 also needs to be created. This time, I created Milestone 9.5.0. We should include it in the release process. https://github.com/apache/lucene/milestone/4 2022年9月3日(土) 4:42 Michael

Subject: New branch and feature freeze for Lucene 9.4.0

NOTICE: Branch branch_9_4 has been cut and versions updated to 9.5 on stable branch. Please observe the normal rules: * No new features may be committed to the branch. * Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all

[no subject]

[no subject]

Hello Folks, We have been using faceted search feature of lucene in our search application without the feature that lets you drill down on a facet dimension. With https://issues.apache.org/jira/browse/LUCENE-8367 you get the ability to skip indexing drill-down terms for top level dimension

[jira] [Commented] (SOLR-13436) Allow SPNEGO SolrJ clients to use doAs Subject

use doAs Subject > -- > > Key: SOLR-13436 > URL: https://issues.apache.org/jira/browse/SOLR-13436 > Project: Solr > Issue Type: Improvement > Security Level: Public(Defaul

[jira] [Created] (SOLR-13436) Allow SPNEGO SolrJ clients to use doAs Subject

Ian Buss created SOLR-13436: --- Summary: Allow SPNEGO SolrJ clients to use doAs Subject Key: SOLR-13436 URL: https://issues.apache.org/jira/browse/SOLR-13436 Project: Solr Issue Type: Improvement

[no subject]

BeastIt Unit Test Beasting Summary Report for Apache Solr Master BeastIt gives unit tests a chance to duke it out in a fair but difficult environment. Each test is beasted and then judged. See a link to the full reports below. Number of Tests: 1108 Number Passed: 1073 % Passed: 96.84% Ran 30

[no subject]

+1 (non-binding) Automated tests were happy for me -- SUCCESS! [1:16:35.519232] I ran a Java API compatibility check between 6.5.0 and this 6.5.1 and while there's a few changes, I don't think any of them would actually end up as user facing. Posted results at

Re: git email format customizability: add branch to subject?

to follow the current pattern at all, note this email... Daniel clarified that at the moment any tag/branch creation/deletion will still come in with a generic subject of "[lucene-solr] Git Push Summary" because that uses a diff code path then most normal commit emails. He pos

Re: git email format customizability: add branch to subject?

mberg.net> : Subject: Re: git email format customizability: add branch to subject? : : : : +1 for keeping the repo name but perhaps we could drop the "git: " prefix? : : : : Without the prefix the subject would still be fairly distinguishable : : from the "svn commit" emai

Re: git email format customizability: add branch to subject?

: +1 for keeping the repo name but perhaps we could drop the "git: " prefix? : : Without the prefix the subject would still be fairly distinguishable : from the "svn commit" emails such as "svn commit: r1731559 - : /lucene/cms/trunk/content/extpaths.txt" (assuming

Re: git email format customizability: add branch to subject?

+1 for keeping the repo name but perhaps we could drop the "git: " prefix? Without the prefix the subject would still be fairly distinguishable from the "svn commit" emails such as "svn commit: r1731559 - /lucene/cms/trunk/content/extpaths.txt" (assum

Re: git email format customizability: add branch to subject?

> "git: %(repo_name)s:%(shortbranch)s: %(subject)s" Looks good to me. I'd keep the repo name regardless of whether it's the main repo or not. Dawid On Sat, Feb 20, 2016 at 4:54 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 2/19/2016 6:04 PM, Ryan Ernst wrote:

Re: git email format customizability: add branch to subject?

On 2/19/2016 6:04 PM, Ryan Ernst wrote: > > This sounds good, but isn't the repo name redundant given it is > implied by the email going to commits@l.a.o? > Right now, I think the only git repository we've got is lucene-solr, but we also receive commit emails from the subversion repository that

Re: git email format customizability: add branch to subject?

gest there is per project flexibility. Branch not one of the > : (currently) available variables though, no? > : > : +1 for "the branch be included in the subject" > > Thanks for finding that link Christine, > > I pinged #infra on HipChat to try and find the actual code

Re: git email format customizability: add branch to subject?

: https://git-wip-us.apache.org/docs/switching-to-git.html seems to : suggest there is per project flexibility. Branch not one of the : (currently) available variables though, no? : : +1 for "the branch be included in the subject" Thanks for finding that link Christine, I pin

Re: git email format customizability: add branch to subject?

On 2/16/2016 11:58 AM, Chris Hostetter wrote: > ...to something closer to what we had with svn... > > Subject: [01/21] lucene-solr: > refs/heads/jira/lucene-5438-nrt-replication git commit: LUCENE-6835: > add test case confirming listAll is sorted; fix dir impls that weren't

Re:git email format customizability: add branch to subject?

https://git-wip-us.apache.org/docs/switching-to-git.html seems to suggest there is per project flexibility. Branch not one of the (currently) available variables though, no? +1 for "the branch be included in the subject" Christine - Original Message - From: dev@lucene.

git email format customizability: add branch to subject?

Does anyone know how much per project flexibility we have on the format of the "git commit" emails sent to commits@lucene ? In particular: is it possible to ask INFRA that the branch be included in the subject, w/o that being a massive change that affects every apache project?

[jira] [Created] (SOLR-7824) Make server kerberos subject available to authorization plugin code

Don Bosco Durai created SOLR-7824: - Summary: Make server kerberos subject available to authorization plugin code Key: SOLR-7824 URL: https://issues.apache.org/jira/browse/SOLR-7824 Project: Solr

[no subject]

http://zarabiaj-internetowo.pl/wp-includes/js/tinymce/plugins/inlinepopups/skins/clearlooks2/img/pinit.php?svhrws1721ezrx Qiang Zhou yczhouqi...@yahoo.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For

[no subject]

http://synergy2000.net/components/com_ag_google_analytics2/google.html - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org

Can the build failure subject line say which modules had failures?

Pulling out an idea Robert suggested... I think it would be awesome if build failure emails included the modules that had test failures. How hard would this be? EG if I did some work on the grouping module and then suddenly I see build failures saying there were failures in grouping that'd make

RE: Can the build failure subject line say which modules had failures?

The Jenkins Email-ext plugin allows content tokens - dynamically interpolated build information - to be included in the generated email subject as well as the body, so assuming there is a way to extract the names of failed modules from the build log, this should be possible. I'm hesitant

Re: Can the build failure subject line say which modules had failures?

subject as well as the body, so assuming there is a way to extract the names of failed modules from the build log, this should be possible. I'm hesitant to say it definitely can be done, though, since the ${BUILD_LOG_MULTILINE_REGEX} content token I set up to be used for the body

[no subject]

[no subject]

[Lucene.Net] Mailing List Subject Line Prefix

All, The mailing lists have been updated to include a subject line prefix of [Lucene.Net]. Please update any mail filters you may have that relate. Thanks, Troy

[no subject]

[no subject]

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

hijacked thread subject!

Sorry, I accidentally hijacked that subject line! Bill Bill Janssen jans...@parc.com wrote: I'm trying to compile iText 5.0.2 with JCC 2.5, and it's choking on this line in a generated .h file: static PdfName *DOMAIN; build/_iText/com/itextpdf/text/pdf/PdfName.h

Re: Changing the subject for a JIRA-issue (Was: [jira] Created: (LUCENE-2335) optimization: when sorting by field, if index has one segment and field values are not needed, do not load String[] into f

: Is it possible to change it? If not, what is the policy here? To open a : new issue and close the old one? ... : In this case, that would mean either closing this issue and opening a new one, : or taking the discussion to the mailing list where subject headers may be : modified

Changing the subject for a JIRA-issue (Was: [jira] Created: (LUCENE-2335) optimization: when sorting by field, if index has one segment and field values are not needed, do not load String[] into field

The current subject and description of https://issues.apache.org/jira/browse/LUCENE-2335 is obsolete due to new knowledge. Is it possible to change it? If not, what is the policy here? To open a new issue and close the old one? Cc: To Michael McCandless as he is the reporter of the issue

Re: Changing the subject for a JIRA-issue (Was: [jira] Created: (LUCENE-2335) optimization: when sorting by field, if index has one segment and field values are not needed, do not load String[] into f

On Tue, Apr 06, 2010 at 11:26:23AM +0200, Toke Eskildsen wrote: The current subject and description of https://issues.apache.org/jira/browse/LUCENE-2335 is obsolete due to new knowledge. Is it possible to change it? If not, what is the policy here? To open a new issue and close the old one

[no subject]

[no subject]

I would like to contribute a class based on the MoreLikeThis class in contrib/queries that generates a query based on the tags associated with a document. The class assumes that documents are tagged with a set of tags (which are stored in the index in a seperate Field). The class determines the

[no subject]

Hello, I'm new in Nutch programming and also on this mailing list. I'd like to change search option. Now it uses BooleanQuery, I need to use WildcardQuery. Is anyone doing something like that? Thanks for help Agnieszka

[no subject]

[no subject]

Hi, I am the lead developer and founder of Hibernate Search (http:// search.hibernate.org). Hibernate Search is a somewhat competitive product of Solr but in a slightly different space. Like Solr it uses Lucene, but while Solr aims at being a search server, Hibernate Search stays in the

[no subject]

A little inconvenience: published API have missed some classes such as WordDelimiterFilter... Thanks, Fuad http://www.tokenizer.org

[no subject]

http://code.google.com/apis/gdata/protocol.html#Optimistic-concurrency The versioning is for updates only.