Re: Welcome Zhang Chao as Lucene committer

Welcome :) On Wed, Feb 21, 2024 at 12:03 PM Dawid Weiss wrote: > > Congratulations and welcome! > > On Tue, Feb 20, 2024 at 6:28 PM Adrien Grand wrote: > >> I'm pleased to announce that Zhang Chao has accepted the PMC's >> invitation to become a committer. >> >> Chao, the tradition is that new

Re: Welcome Stefan Vodita as Lucene committter

Welcome! Congratulations. On Fri, Jan 19, 2024 at 12:56 PM Greg Miller wrote: > Welcome Stefan! Glad to have you! > > On Fri, Jan 19, 2024 at 08:00 Michael Sokolov wrote: > >> Hello Stefan, welcome! >> >> On Fri, Jan 19, 2024 at 10:41 AM Martin Gainty >> wrote: >> >>> Congratulations Stefan!

Re: Welcome Patrick Zhai to the Lucene PMC

Welcome :) On Mon, Nov 13, 2023 at 1:15 PM Anshum Gupta wrote: > Congratulations and welcome, Patrick! > > On Fri, Nov 10, 2023 at 12:05 PM Michael McCandless < > luc...@mikemccandless.com> wrote: > >> I'm happy to announce that Patrick Zhai has accepted an invitation to >> join the Lucene

Re: Bump minimum Java version requirement to 21

For perspective, I'm still seeing java 11 as the norm for clients... 17 is uncommon. Anything requiring 21 is likely to be difficult to sell. I am however a small shop, and "migrating off of solr 6" and "trying out solr cloud" is still a thing for some clients. Just a datapoint/anecdote, possibly

Re: Squash vs merge of PRs

>> Also, one can always wear hazy glasses in the future to "summarize" the >> full history down to a view that's more palatable to them personally, if >> you don't like seeing merge commit branching. But we cannot do the >> reverse. Discarding the actual developm

Re: Squash vs merge of PRs

Also, since (as noted) this is a previously decided issue, not sure why this is a list email instead of a simple direct query to Robert seeking to understand the specific case? No need to make a public discussion unless it's a long term pattern, actually breaking something, or we want to change

Re: Running 10.0 build with a custom lucene 9.5

Ok pushed an attempt at a clearer message. LMK what you think. On Tue, May 16, 2023 at 11:30 PM Gus Heck wrote: > Ok reading my last message I realize it still might not be clear. Here's > what I observed: > > The class Codec clearly loaded, (from the lucene-core jar) when > Cod

Re: Running 10.0 build with a custom lucene 9.5

the right policy file). -Gus On Tue, May 16, 2023 at 11:10 PM Gus Heck wrote: > Oh hmm the google UI hid the quoted bit. If you don't like message let's > improve it. (actually, it should probably say the "file in the jar"... or > something a little more specific... n

Re: Running 10.0 build with a custom lucene 9.5

ar without the FilePermission to (re?) access the jar it seems) On Tue, May 16, 2023 at 11:05 PM Gus Heck wrote: > I propose to improve the message on an exception already thrown. > > On Tue, May 16, 2023 at 11:04 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >&

Re: Running 10.0 build with a custom lucene 9.5

is the case, it just ignores the jar! > > Are you serious? > > On Wed, 17 May, 2023, 8:02 am Gus Heck, wrote: > >> Blaming? >> >> On Tue, May 16, 2023 at 10:05 PM Ishan Chattopadhyaya < >> ichattopadhy...@gmail.com> wrote: >> >>> > H

Re: [VOTE] Dimension Limit for KNN Vectors

he crazy heap memory usage or other issues of KNN implementation > causing shit like OOM on merge. But it is one step: > https://github.com/apache/lucene/issues/12302 > > > > On Tue, May 16, 2023 at 7:45 AM Gus Heck wrote: > >> Robert, >> >> Can you explain in

Re: Running 10.0 build with a custom lucene 9.5

Blaming? On Tue, May 16, 2023 at 10:05 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > > Having that explicitly called out would have been SUPER helpful. > > Blaming Java in an exception thrown by Lucene is a ridiculous idea. > > On Wed, 17 May, 2023,

Re: Running 10.0 build with a custom lucene 9.5

es/12300 On Mon, May 15, 2023 at 3:17 PM Michael Sokolov wrote: > random guess - does it have something to do with modules? > > On Mon, May 15, 2023 at 11:14 AM Gus Heck wrote: > > > > I hadn't seen that one. Thanks, I'll look at it. It already looks a bit > confusing th

Re: [VOTE] Dimension Limit for KNN Vectors

Actually, I had wondered if this is a proper vote thread or not, normally those are yes/no on a single option. On Tue, May 16, 2023 at 10:47 AM Alessandro Benedetti wrote: > Hi Marcus, > I am afraid at this stage Robert's opinion counts just as any other > opinion, a single vote for option 1. >

Re: [VOTE] Dimension Limit for KNN Vectors

Robert, Can you explain in clear technical terms the standard that must be met for performance? A benchmark that must run in X time on Y hardware for example (and why that test is suitable)? Or some other reproducible criteria? So far I've heard you give an *opinion* that it's unusable, but

Re: Running 10.0 build with a custom lucene 9.5

ry - META-INF not WEB-INF >> > >> > On Sat, May 13, 2023 at 10:12 AM Michael Sokolov >> wrote: >> > > >> > > You are probably missing the contents of WEB-INF in your custom jar? >> > > Roughly speaking the files in there define run-time-bound

Fwd: Running 10.0 build with a custom lucene 9.5

are failing I can't see the ones that are passing easily). -- Forwarded message - From: Gus Heck Date: Wed, May 10, 2023 at 6:50 PM Subject: Running 10.0 build with a custom lucene 9.5 To: Lucene: - I made a tweak to lucene for something I'm investigating, gave it a new

Re: Conneting Lucene with ChatGPT Retrieval Plugin

Do you anticipate that the vector engine would be changed in a way that fundamentally precluded larger vectors (intentionally)? I would think that the ability to support larger vectors should be a key criteria for any changes to be made. Certainly if there are optimizations to be had at specific

Why two TermAndBoost classes

Was fishing around in parsers in solr and discovered that we have two different term and boost classes in Lucene. Is this really desirable? They are quite similar except one implements a notion of equality, and doesn't copy the BytesRef when created whereas the other relies on object equality and

Re: [Proposal] Remove max number of dimensions for KNN vectors

His point is that we, as a dev community, are not paying enough attention > to the indexing performance of our KNN algo (HNSW) and implementation, and > that it is reckless to increase / remove limits in that state. > If the argument were... "Please hold off while I'm actively improving this, it

Re: [Proposal] Remove max number of dimensions for KNN vectors

Also technically, it's just the threat of a veto since we are not actually in a vote thread On Sun, Apr 9, 2023 at 12:46 PM Gus Heck wrote: > What I see so far: > >1. Much positive support for raising the limit >2. Slightly less support for removing it or making it

Re: [Proposal] Remove max number of dimensions for KNN vectors

What I see so far: 1. Much positive support for raising the limit 2. Slightly less support for removing it or making it configurable 3. A single veto which argues that a (as yet undefined) performance standard must be met before raising the limit 4. Hot tempers (various) making

Re: [Proposal] Remove max number of dimensions for KNN vectors

10 MB hard drive, wow I'll never need another floppy disk ever... Neural nets... nice idea, but there will never be enough CPU power to run them... etc. Is it possible to make it a configurable limit? On Wed, Apr 5, 2023 at 4:51 PM Jack Conradson wrote: > I don't want to get too far off

Re: Lucene PMC Chair Greg Miller

Congratulations Greg and thanks Bruno! On Tue, Mar 7, 2023 at 3:13 PM Tomás Fernández Löbbe wrote: > Thanks Bruno! and Congratulations Greg! > > On Tue, Mar 7, 2023 at 10:49 AM Patrick Zhai wrote: > >> Thank you Bruno and Greg! >> >> On Tue, Mar 7, 2023, 10:40 Mikhail Khludnev wrote: >> >>>

Re: [DISCUSS:] Reproducible Builds

could be > the JAR *exclusive* of its MANIFEST.MF. There is some interesting metadata > in there -- not essential but a shame to throw away in the name of > reproducibility. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > &

[DISCUSS:] Reproducible Builds

Some discussion on https://github.com/apache/lucene/pull/12096 lead to the question of whether or not reproducible builds ( https://reproducible-builds.org/) are something we would like to work towards. I'm a fan, though unlikely to have time to work on it soon. What I can do is monitor this

Re: Request for naming help

to something like “Range > Relation Faceting,” but fear that would be confusing. > > Thanks again! > > Cheers, > -Greg > > On Mon, Dec 12, 2022 at 10:19 Gus Heck wrote: > >> Maybe "Range Intersect Faceting"? >> >> On Mon, Dec 12, 2022 at 1:1

Re: Request for naming help

Maybe "Range Intersect Faceting"? On Mon, Dec 12, 2022 at 1:11 PM Greg Miller wrote: > Folks- > > Naming is hard! (But you all know that already). > > Marc D'Mello and I have been working on a new faceting implementation > that's meant to complement Lucene's existing range-relation queries

Re: Welcome Luca Cavanna as Lucene committer

Welcome :) On Wed, Oct 5, 2022 at 5:38 PM Michael McCandless wrote: > Welcome Luca! > > Mike > > On Wed, Oct 5, 2022 at 4:37 PM Tomás Fernández Löbbe < > tomasflo...@gmail.com> wrote: > >> Congratulations Luca!! >> >> On Wed, Oct 5, 2022 at 2:19 PM Vigya Sharma wrote: >> >>> Congratulations

Re: Code coverage check for PRs

One thing codecov gives is a sense of what the coverage was previously without having to go hunt down past builds in jenkins. It is a coverage focused view essentially. It just uses the coverage data the build already calculates. It used to have some nifty graphical visualizations but those seem

Re: Welcome Vigya Sharma as Lucene committer

Welcome! On Thu, Jul 28, 2022 at 11:24 AM Julie Tibshirani wrote: > Congratulations Vigya! > > On Thu, Jul 28, 2022 at 6:34 AM Mayya Sharipova > wrote: > >> Congratulations and welcome Vigya! >> >> >> On Thu, Jul 28, 2022 at 9:31 AM Nhat Nguyen >> wrote: >> >>> Welcome, Vigya! >>> >>> On Thu,

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

I am 100% for preventing creation of new issues in Jira, new issues should only be created in one system at any one time. I feel that existing issues should be completed in their original system for continuity, and anticipate that in any case Jira will mean readable in perpetuity. The copying of

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

I hope you count me as someone who sees history as important. It's important in more ways than one however. You gave the example of trying to understand something, and looking at the issue history directly. I also give weight to the scenario where someone has written a blog post about the topic

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

+1 to your suggestion. On Thu, Jun 16, 2022 at 12:34 AM Tomoko Uchida wrote: > We have two conflicting requests: > 1. We don't want to duplicate/diverge issues; an issue's identity is > what matters the most. > 2. We don't want to keep holding multiple issue systems; having only > one system is

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

I agree with the idea that we shouldn't have 2 active trackers, but I think that the apache jira must remain readable forever. People will have bookmarked or linked issues in documents, blog posts or web pages and breaking those links would be a HUGE disservice to the community. Ideally we would

Re: Welcome Greg Miller to the Lucene PMC

Welcome Greg :) On Tue, Jun 7, 2022 at 5:43 PM David Smiley wrote: > Welcome Greg! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Jun 7, 2022 at 2:44 AM Adrien Grand wrote: > >> I'm pleased to announce that Greg Miller has

Re: Welcome Chris Hegarty as Lucene committer

Welcome and congratulations :) On Wed, Jun 1, 2022 at 4:50 PM Martin Gainty wrote: > Welcome Chris! > martin > -- > *From:* Tomoko Uchida > *Sent:* Wednesday, June 1, 2022 11:05 AM > *To:* Lucene Dev > *Subject:* Re: Welcome Chris Hegarty as Lucene committer > >

Re: Welcome Lu Xugang as Lucene committer

Welcome and congratulations :) On Wed, Jun 1, 2022 at 3:32 PM Alessandro Benedetti wrote: > Welcome on board Xugang! > -- > *Alessandro Benedetti* > CEO @ Sease Ltd. > *Apache Lucene/Solr Committer* > *Apache Solr PMC Member* > > e-mail: a.benede...@sease.io > > >

Re: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

-1 I think the disruption and bifurcation of where to find history is not worth it. I also noticed a comment in the lucene issue for migration with summaries by date range, status, affects version, etc. sub-area, exactly the sort of thing I expect to be much more difficult to obtain from github.

Re: Bugfix release Lucene/Solr 8.11.2

SOLR-16194 is in and ported to 8.11,.2 On Wed, May 18, 2022 at 7:12 AM Jan Høydahl wrote: > I was pinged on https://issues.apache.org/jira/browse/SOLR-16019 because > I have an in-flight PR with a backport. I'll complete and merge that PR. > > Jan > > > 13. mai 2022 kl. 01:03 skrev Mike Drob :

Re: Bugfix release Lucene/Solr 8.11.2

commit and backport of course :) On Sun, May 15, 2022 at 7:47 PM Gus Heck wrote: > https://issues.apache.org/jira/browse/SOLR-16194 now has a PR ( > https://github.com/apache/solr/pull/864) will commit after review or 3 > days without objections > > On Fri, May 13, 2022 at 12

Re: Bugfix release Lucene/Solr 8.11.2

https://issues.apache.org/jira/browse/SOLR-16194 now has a PR ( https://github.com/apache/solr/pull/864) will commit after review or 3 days without objections On Fri, May 13, 2022 at 12:19 PM Gus Heck wrote: > I think it would be good if we can get > https://issues.apache.org/jira/brows

Re: Bugfix release Lucene/Solr 8.11.2

I think it would be good if we can get https://issues.apache.org/jira/browse/SOLR-16194 into 8.11.2 I plan to work on it this weekend. I'm hoping it will be a straightforward matter of adding a check for existing collections. On Fri, May 13, 2022 at 4:21 AM Anshum Gupta wrote: > Yes please! I

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

itters the best? >>>> >>>> To me Github comes up on top, even though there are things that JIRA >>>> does better. >>>> >>>> P.S. I think you mean https://github.com/helm/charts, marcus. I don't >>>> think helm is deprecated >

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

On Tue, May 10, 2022 at 10:40 AM Houston Putman wrote: > >> > Most modern open source projects use Github Issues for their issue > tracking, so it's definitely doable, and really what new > users/contributors will be expecting. Also I see that much discussion is > already done on PRs, and JIRAs

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

Yes, the listing of differences (that we rely on) of course has two resolution paths to facilitate such a move. A) find a way to fill the gap B) decide we don't care about the gap - either is fine so long as it's an intentional decision, not an oops we discover and regret later. On Tue, May 10,

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

I knew I had seen an apache issue tracker project... https://bloodhound.apache.org/ which evidently descends from Trac, but it appears to be more or less dead with no activity easily seen since 2014 :( On Mon, May 9, 2022 at 10:27 AM Gus Heck wrote: > Ok my quick search led me astray I some

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

Ok my quick search led me astray I somehow thought Jackrabbit was an isuse tracker because I landed on that page first.. disregard that. On Mon, May 9, 2022 at 10:19 AM Gus Heck wrote: > On the suggestion of private security only repo in another mail... that > seems to mean security issu

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

On the suggestion of private security only repo in another mail... that seems to mean security issues can never be made public? Presently we have a culture of openness where once the issue is resolved and a fix release we share the discussion. I think that's good since it can then lead security

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

I think both tools have their merits and drawbacks What I like about Jira: - It has ample room and configuration for issue metadata and customizable workflows and in general a deep feature set - It has user roles, PMC members can see security issues that are hidden from the world...

Re: Welcome Guo Feng as Lucene committer

Welcome! On Tue, Jan 25, 2022 at 9:57 AM Michael McCandless < luc...@mikemccandless.com> wrote: > Welcome Feng! > > Mike > > On Tue, Jan 25, 2022 at 4:09 AM Adrien Grand wrote: > >> I'm pleased to announce that Guo Feng has accepted the PMC's >> invitation to become a committer. >> >> Feng, the

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

Welcome :) On Sun, Dec 19, 2021 at 9:48 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > Welcome Haoyu! > > On Sun, 19 Dec, 2021, 7:16 pm Michael McCandless, < > luc...@mikemccandless.com> wrote: > >> Welcome Patrick! >> >> Mike >> >> On Sun, Dec 19, 2021 at 8:44 AM Robert Muir

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set

would be to add independent entries to the security news page for the newer CVE's On Sat, Dec 18, 2021 at 12:20 PM Gus Heck wrote: > I think perhaps in the shock of such a deep and surprising vulnerability > with such high visibility, we've begun to break with how we normally handle &

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set

> Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > *From:* Gus Heck > *Sent:* Wednesday, December 15, 2021 12:39 AM > *To:* dev > *Subject:* Re: Log4j < 2.15.0 may still be vulnerable even

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

fast track please :) On Wed, Dec 15, 2021 at 7:23 PM Anshum Gupta wrote: > Fast-track please :) > > On Wed, Dec 15, 2021 at 4:19 PM Jan Høydahl wrote: > >> Given the votes so far (11 binding +1) I'm also positive to publish >> tomorrow, and not wait for Friday. >> The release voting rules are

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

+1 (binding) smoke tester pass, local 4 node cluster started via cloud.sh (-r to build from local check out of 0b002b11819df70783e83ef36b42ed1223c14b50) created 2 collections added one doc to each, queried each and both via an alias. On Wed, Dec 15, 2021 at 11:17 AM Jan Høydahl wrote: > I

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set

Perhaps we could tweak it to say that the system property fix is sufficient *for Solr* (i.e. not imply that it is a valid work around for all cases) On Tue, Dec 14, 2021 at 6:20 PM Uwe Schindler wrote: > The other attack vectors are also not possible with Solr: > > - Logger.printf("%s",

Re: Maven publication with the Gradle build

Hmm do the RC builds have an RC1,RC2,etc notation in the version so one can tell which one is running? (and if you've really restarted to the intended version etc when testing/comparing them)? if so we'd be rebuilding anyway to get rid of it? On Mon, Dec 6, 2021 at 10:41 AM Dawid Weiss wrote: >

Re: Welcome Julie Tibshirani to the Lucene PMC

Welcome :) On Tue, Nov 30, 2021 at 5:45 PM Michael Sokolov wrote: > yup I checked and you are there: > https://whimsy.apache.org/roster/committee/lucene -- just curious, > does anyone know why some of our names are **bold** on that list? > > On Tue, Nov 30, 2021 at 5:19 PM Michael Sokolov >

Re: [VOTE] Release Lucene 9.0.0 RC3

ile or about the > instructions to build the package in general? If it's the latter then > I think it's fine? > > Dawid > > On Mon, Nov 29, 2021 at 2:16 PM Gus Heck wrote: > > > > Not suggesting it's a show stopper, just that this would be an easily > found and cons

Re: [VOTE] Release Lucene 9.0.0 RC3

pplies to any 9x branch - > > perhaps starting from main. We can extract these instructions into a > > separate document. On the other hand, it wouldn't be shown up there on > > github front-page then... and times have changed - this is where most > > folks would probably end

Re: [VOTE] Release Lucene 9.0.0 RC3

Seems to me the details for how to turn a src tarball into something that can be compiled should go in a BUILDING.txt file? On Mon, Nov 29, 2021 at 3:00 AM Dawid Weiss wrote: > SUCCESS! [0:17:23.949074] > > +1. > > D. > > On Fri, Nov 26, 2021 at 3:31 PM Adrien Grand wrote: > > > > Please vote

Re: [VOTE] Release Lucene 9.0.0 RC3

+1 SUCCESS! [0:08:46.711289] (Java 11 JAVA_HOME=/home/gus/../zulu11.48.21-ca-jdk11.0.11-linux_x64/) Smoketester only On Sat, Nov 27, 2021 at 10:57 AM Tomoko Uchida wrote: > Luke app starts on both of Linux and Windows (with or without spaces > in the path) and works well for me. > Thanks

Re: What should we do of branch_8x?

t;>>> Sorry, but this discussion is complete nonsense. Its just version >>>>> numbers and some hick-hack between two parties that disagree. Keep calm >>>>> and >>>>> don’t try to make it overcomplicated! >>>>> >>>>>

Re: What should we do of branch_8x?

Release of Solr 8.12 It should require the current lucene-solr 8.x branch to remove the lucene bits and declare a dependency on lucene 8.11 lucene, that bit shouldn't be too hard if done soon... and the release process for 8.x would not publish a lucene artifact which is likely the harder bit. I

Re: [VOTE] Release Lucene/Solr 8.11.0 RC1

+1 SUCCESS! [0:54:16.982080] On Tue, Nov 9, 2021 at 9:06 PM Mayya Sharipova wrote: > +1 SUCCESS! [1:09:47.023515] > > On Tue, Nov 9, 2021 at 6:42 PM Timothy Potter > wrote: > >> totally unofficial, but I posted a Docker image for testing 8.11.0 RC1 >> on K8s here:

Re: Welcome Mayya Sharipova to the Lucene PMC

Welcome :) On Mon, Jun 28, 2021, 6:30 PM Anshum Gupta wrote: > Congratulations and welcome, Mayya! > > On Mon, Jun 28, 2021 at 6:16 AM Robert Muir wrote: > >> I am pleased to announce that Mayya has accepted an invitation to join >> the Lucene PMC! >> >> Congratulations, and welcome aboard! >>

Re: Welcome Greg Miller as Lucene committer

Welcome Greg :) On Tue, Jun 1, 2021 at 12:03 AM Tomás Fernández Löbbe wrote: > Congrats Greg!! > > On Mon, May 31, 2021 at 9:37 AM Gautam Worah > wrote: > >> Congratulations Greg :) >> >> On Mon, May 31, 2021, 8:02 AM Ilan Ginzburg wrote: >> >>> Congrats Greg! >>> >>> On Sun, May 30, 2021 at

Re: Release Lucene/Solr 8.9.0 should we have it soon

anks everyone, > > > > Adrien, I am happy to try to be a release manager for this release. > > > > Adrien, and Gus, please let me know when your changes are merged to 8.x > > > > > > > > On Tue, May 11, 2021 at 10:38 AM Gus Heck wrote: > >> > &g

Re: Release Lucene/Solr 8.9.0 should we have it soon

I'm also looking to find time to get https://issues.apache.org/jira/browse/SOLR-14597 into some sort of 8x. I've recently completed the back port of 2/3 of the lucene tickets that are related, and hope to work on the third tomorrow I had some feedback there, but I think folks were waiting for

Re: Welcome Zach Chen as Lucene committer

Welcome Zach :) On Mon, Apr 19, 2021 at 1:09 PM Xi Chen wrote: > Thanks Adrien for the announcement and everyone for the warm welcome! I’m > deeply honored to be able to join this great community! > > > I work at Amazon Lab126 and have been involved in voice bot / chat bot > development for the

Re: Welcome Peter Gromov as Lucene committer

Welcome! On Tue, Apr 6, 2021 at 2:16 PM Mike Drob wrote: > Welcome! > > On Tue, Apr 6, 2021 at 1:06 PM Dawid Weiss wrote: > >> Congratulations and welcome, Peter! >> >> Dawid >> >> On Tue, Apr 6, 2021 at 7:48 PM Robert Muir wrote: >> > >> > I'm pleased to announce that Peter Gromov has

Re: Welcome Bruno to the Apache Lucene PMC

Welcome :) On Thu, Mar 11, 2021 at 9:58 AM Houston Putman wrote: > Congrats and welcome Bruno! > > On Thu, Mar 11, 2021 at 8:32 AM David Smiley wrote: > >> Welcome Bruno! >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Wed, Mar

Re: Lucene/Solr Code of Conduct and etiquette

Another thought looking at the top of that page (and somewhat off topic), though obviously mentioned elsewhere, the first line of support should probably the Ref Guide. Not that it can't be found elsewhere, but it should probably be the first place folks look. On Wed, Mar 3, 2021 at 2:14 AM

Re: Lucene/Solr Code of Conduct and etiquette

I like the sentiments in all of those links. I'd be +1 on including all 3 conduct, etiquette and apacheway links. On Tue, Mar 2, 2021 at 4:46 AM Atri Sharma wrote: > +1 > > On Tue, 2 Mar 2021, 15:01 Jan Høydahl, wrote: > >> Hi community! >> >> The Apache Software Foundation has a

Re: Revisiting Standardized Test Names in Solr

t; we not make a sweeping change like this until after Mark's "ref branch" is > reconciled. I don't want that to hang over the project indefinitely, but > we can wait; we've not had this standardization yet for many years, after > all. > > That said, it would be good to choose t

Re: Proposal for the Lucene Dependency after git repo split

sing released lucene versions as dependencies for every >> version branch in Solr. >> >> On Thu, Feb 25, 2021 at 5:49 PM Gus Heck wrote: >> >>> Until the first feature that wants to add something on both fronts... Is >>> it possible for Lucene to publish nigh

Re: Proposal for the Lucene Dependency after git repo split

Until the first feature that wants to add something on both fronts... Is it possible for Lucene to publish nightly snapshots? I know there is some level of support for snapshots in central, though I don't know what their usage policies are. If that's too restricted is there an artifact repo

Re: Revisiting Standardized Test Names in Solr

FWIW, I'm not really in favor of the convention Lucene adopted. I probably lost track of the debate and failed to object which is on me, but I guess it was because that was the lower number of changes there? It's certainly much less legible in the IDE to have a wall of classes all starting with T.

Re: Simplifying source pattern checks

t gets noticed by everyone "Watching" the original > issue, even if it's old. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Sat, Feb 20, 2021 at 5:14 PM Gus Heck wrote: > >> I noticed today that

Simplifying source pattern checks

I noticed today that SOLR-10883 added checks for patterns that didn't play nice with PDF generation. Now that we don't generate the PDF anymore perhaps we can do away with those checks? Anyone have thoughts to the contrary? https://issues.apache.org/jira/browse/SOLR-10883 -Gus --

Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!

Congratulations :) On Wed, Feb 17, 2021 at 5:42 PM Tomás Fernández Löbbe wrote: > Congratulations Mike! > > On Wed, Feb 17, 2021 at 2:42 PM Steve Rowe wrote: > >> Congrats Mike! >> >> -- >> Steve >> >> > On Feb 17, 2021, at 4:31 PM, Anshum Gupta >> wrote: >> > >> > Every year, the Lucene PMC

Re: Hunspell performance

> > I don't have any confidence that solr would default to the "smaller" > option or fix how they manage different solr cores or thousands of > threads or any of the analyzer issues. Certainly there's work to be done there. Many things to improve. Separate issue however. > And who would

Re: Hunspell performance

+1 to configurability that is well documented, and reasonably actionable downstream in Solr... Some folks struggle with the costs of buying machines with lots of memory. On Wed, Feb 10, 2021 at 3:05 PM Dawid Weiss wrote: > > >> To me the challenge with such a change is just trying to prevent >

Re: [DISCUSS] ConfigSet ZK to file system fallback

> > I'd prefer it being an explicit fallback or resolution order instead of > hardcoded magick. > I.e. able to configure a configset search path such as ["local", "zk", > "somethingelse"]. This would make resource loader prefer local files even > if they exist in ZK. > > This actually winds up

Re: [DISCUSS] ConfigSet ZK to file system fallback

It sounds like the issue is that we need both a "per node config" and a "per collection" config. This could all be in zookeeper, and with a clear well documented precedence order (node wins) for any attributes that overlap... would even make sense to have names for nodes that were not literal

Re: [DISCUSS] ConfigSet ZK to file system fallback

I'm in agreement with Eric here that fewer ways (or at least a clearer default way) of supplying resources would be better. Additionally, it should be easy to specify that this resource that I've shared should be loaded on a per SolrCore or per node basis (or even better per collection present on

Re: Consider Removing the `@` Special Character from RegExp

I think it's already an optional feature; if you construct the regexp with explicit syntax flags you can get an instance that won't consider '@' special. Haven't actually had a need to do that so I'm assuming it works as documented. /** Syntax flag, enables anystring (@). */ public static final

Re: Old programmers do fade away

Good luck and enjoy the welder. I did some welding many years ago, and it's quite a cool thing to turn two bits of metal into a single piece. Hopefully you've not had to learn about the UV emissions given off by the arc by getting a good solid sunburn the way I did :). The community will

Re: Code reformatting

+1 to always braces On Thu, Dec 24, 2020 at 11:47 AM Michael Sokolov wrote: > The Google convention you cited says this, I think? > > >Braces are used with if, else, for, do and while statements, even > when the body is empty or contains only a single statement. > > On Thu, Dec 24, 2020 at

Re: Welcome Houston Putman to the PMC

Congratations :) On Tue, Dec 1, 2020, 9:53 PM Martin Gainty wrote: > congrats Houston > martin​ > > -- > *From:* Yonik Seeley > *Sent:* Tuesday, December 1, 2020 7:35 PM > *To:* Solr/Lucene Dev > *Subject:* Re: Welcome Houston Putman to the PMC > > Congrats

Re: Welcome Julie Tibshirani as Lucene/Solr committer

Congratulations and welcome :) On Wed, Nov 18, 2020 at 10:56 AM Houston Putman wrote: > Congrats and welcome Julie!! > > - Houston > > On Wed, Nov 18, 2020 at 10:30 AM Eric Pugh < > ep...@opensourceconnections.com> wrote: > >> I’ve seen all your contributions, really great stuff. Welcome! >> >>

Re: Lucene Query Parser Syntax Specification

I have had this thought regarding IDE support too. I've had expressions that when formatted for legibility are over 100 lines long, and adding something in the middle that changes indenting is truly painful at that point. At the moment I've got several irons in the fire already and can't possibly

Re: 8.8 section in the changelog?

That is only for master, because I was intending on merging back after the branch so all aqp related features would stay together and to not drop it in 8.7 with no time for it to get used/validated by the motivating use case. On Fri, Oct 16, 2020, 1:07 PM Adrien Grand wrote: > Hello, > > I'm

Re: Index documents in async way

This is interesting, though it opens a few of cans of worms IMHO. 1. Currently we now guarantee that if solr sends you an OK response the document WILL eventually become searchable without further action. Maintaining that guarantee becomes impossible if we haven't verified that the

Re: QueryParser - proposed change may break existing queries.

And as I understand it, current behavior is the silent misinterpretation. To me, the failure to require a space after the regex (and either not become a regex in that case or complain about invalid regex) might be considered a bug... On Thu, Sep 17, 2020 at 9:30 AM Mark Harwood wrote: > I think

Re: 8.7 Release

Unless it somehow got lost in a spam filter somewhere, I don't think we have set a target date for the release yet? (roadmap says autumn 2020 which technically doesn't begin until the solstice on the 21st :) ) Hoping that I might still get the Advanced Query parser in first, but that's a much

Re: Avoiding false-positives in multivalued field search with intervals?

You're thinking of SurroundQuery parser for span queries I think... https://lucene.apache.org/solr/guide/8_6/other-parsers.html#surround-query-parser and the Advanced Query Parser will have a similar syntax On Thu, Sep 10, 2020 at 4:40 PM Michael Sokolov wrote: > A slightly different but

PayloadDecoder.FLOAT_DECODER

In reviewing SOLR-14787 , with the author verbally, he pointed out there's some duplicated code where he needed to decode a payload into a float. We have org.apache.lucene.analysis.payloads.PayloadHelper#decodeFloat(byte[], int) but

Re: [VOTE] Lucene logo contest, third time's a charm

A2, A1, D (binding) On Tue, Sep 1, 2020 at 7:37 PM Varun Thacker wrote: > (non-binding) > vote: A1, A2, D > > On Tue, Sep 1, 2020 at 1:21 PM Ryan Ernst wrote: > >> Dear Lucene and Solr developers! >> >> Sorry for the multiple threads. This should be the last one. >> >> In February a contest

  1   2   3   4   5   6   7   8   9   10   >