Re: Lucene v9.9.1: org.apache.lucene.search.ScoreMode

It’s there for sure, but that doesn’t mean there is no problem. Could you share what you are seeing in more detail given the class certainly exists? Marcus Eagan On Sat, Jan 6, 2024 at 14:05 Chris Hegarty wrote: > Hi, > > I see no issue. ScoreMode is present in lucene-core-

Re: Welcome Luca Cavanna to the Lucene PMC

accepted an invitation to >> join the Lucene PMC! >> >> Congratulations Luca, and welcome aboard! >> >> >> -- >> Adrien >> > -- Marcus Eagan

Re: Patch to change murmurhash implementation slightly

gt; >> > Cheers, >>> >>>>> >> >> >> >> > Thomas >>> >>>>> >> >> >> >> > >>> >>>>> >> >> >> >> > On Tue, Apr 25, 2023 at 3:07 PM Robert Muir < >>> rcm...@gmail.com> wrote: >>> >>>>> >> >> >> >> >> >>> >>>>> >> >> >> >> >> i think from my perspective it has nothing to do >>> with cpus being >>> >>>>> >> >> >> >> >> 32-bit or 64-bit and more to do with the average >>> length of terms in >>> >>>>> >> >> >> >> >> most languages being smaller than 8. for the >>> languages with longer >>> >>>>> >> >> >> >> >> word length, its usually because of complex >>> morphology that most users >>> >>>>> >> >> >> >> >> would stem away. so doing 4 bytes at a time seems >>> optimal IMO. >>> >>>>> >> >> >> >> >> languages from nature don't care about your cpu. >>> >>>>> >> >> >> >> >> >>> >>>>> >> >> >> >> >> On Tue, Apr 25, 2023 at 8:52 AM Michael McCandless >>> >>>>> >> >> >> >> >> wrote: >>> >>>>> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> > For a truly "pure" indexing test I usually use a >>> single thread for indexing, and SerialMergeScheduler (using that single >>> thread to also do single-threaded merging). It makes the indexing take >>> forever lol but it produces "comparable" results. >>> >>>>> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> > But ... this sounds like a great change anyway? >>> Do we really need to gate it on benchmark results? Do we think there could >>> be a downside e.g. slower indexing on (the dwindling) 32 bit CPUs? >>> >>>>> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> > Mike McCandless >>> >>>>> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> > http://blog.mikemccandless.com >>> >>>>> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> > On Tue, Apr 25, 2023 at 7:39 AM Robert Muir < >>> rcm...@gmail.com> wrote: >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> I think the results of the benchmark will depend >>> on the properties of >>> >>>>> >> >> >> >> >> >> the indexed terms. For english wikipedia >>> (luceneutil) the average word >>> >>>>> >> >> >> >> >> >> length is around 5 bytes so this optimization >>> may not do much. >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> On Tue, Apr 25, 2023 at 1:58 AM Patrick Zhai < >>> zhai7...@gmail.com> wrote: >>> >>>>> >> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> >> > I did a quick run with your patch, but since I >>> turned on the CMS as well as TieredMergePolicy I'm not sure how fair the >>> comparison is. Here's the result: >>> >>>>> >> >> >> >> >> >> > Candidate: >>> >>>>> >> >> >> >> >> >> > Indexer: indexing done (890209 msec); total >>> 2620 docs >>> >>>>> >> >> >> >> >> >> > Indexer: waitForMerges done (71622 msec) >>> >>>>> >> >> >> >> >> >> > Indexer: finished (961877 msec) >>> >>>>> >> >> >> >> >> >> > Baseline: >>> >>>>> >> >> >> >> >> >> > Indexer: indexing done (909706 msec); total >>> 2620 docs >>> >>>>> >> >> >> >> >> >> > Indexer: waitForMerges done (54775 msec) >>> >>>>> >> >> >> >> >> >> > Indexer: finished (964528 msec) >>> >>>>> >> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> >> > For more accurate comparison I guess it's >>> better to use LogxxMergePolicy and turn off CMS? If you want to run it >>> yourself you can find the lines I quoted from the log file. >>> >>>>> >> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> >> > Patrick >>> >>>>> >> >> >> >> >> >> > >>> >>>>> >> >> >> >> >> >> > On Mon, Apr 24, 2023 at 12:34 PM Thomas >>> Dullien wrote: >>> >>>>> >> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >> Hey all, >>> >>>>> >> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >> I've been experimenting with fixing some >>> low-hanging performance fruit in the ElasticSearch codebase, and came >>> across the fact that the MurmurHash implementation that is used by >>> ByteRef.hashCode() is reading 4 bytes per loop iteration (which is likely >>> an artifact from 32-bit architectures, which are ever-less-important). I >>> made a small fix to change the implementation to read 8 bytes per loop >>> iteration; I expected a very small impact (2-3% CPU or so over an indexing >>> run in ElasticSearch), but got a pretty nontrivial throughput improvement >>> over a few indexing benchmarks. >>> >>>>> >> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >> I tried running Lucene-only benchmarks, and >>> succeeded in running the example from >>> https://github.com/mikemccand/luceneutil - but I couldn't figure out >>> how to run indexing benchmarks and how to interpret the results. >>> >>>>> >> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >> Could someone help me in running the >>> benchmarks for the attached patch? >>> >>>>> >> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >> Cheers, >>> >>>>> >> >> >> >> >> >> >> Thomas >>> >>>>> >> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >> >>> - >>> >>>>> >> >> >> >> >> >> >> To unsubscribe, e-mail: >>> dev-unsubscr...@lucene.apache.org >>> >>>>> >> >> >> >> >> >> >> For additional commands, e-mail: >>> dev-h...@lucene.apache.org >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >> >>> - >>> >>>>> >> >> >> >> >> >> To unsubscribe, e-mail: >>> dev-unsubscr...@lucene.apache.org >>> >>>>> >> >> >> >> >> >> For additional commands, e-mail: >>> dev-h...@lucene.apache.org >>> >>>>> >> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >>> >>>>> >> >> >> >> >> >>> - >>> >>>>> >> >> >> >> >> To unsubscribe, e-mail: >>> dev-unsubscr...@lucene.apache.org >>> >>>>> >> >> >> >> >> For additional commands, e-mail: >>> dev-h...@lucene.apache.org >>> >>>>> >> >> >> >> >> >>> >>> >>> >>> >>> >>> - >>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> > > -- > Marcus Eagan > > -- Marcus Eagan

Re: Patch to change murmurhash implementation slightly

;> >> >> >> most languages being smaller than 8. for the >> languages with longer >> >>>>> >> >> >> >> >> word length, its usually because of complex >> morphology that most users >> >>>>> >> >> >> >> >> would stem away. so doing 4 bytes at a time seems >> optimal IMO. >> >>>>> >> >> >> >> >> languages from nature don't care about your cpu. >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> On Tue, Apr 25, 2023 at 8:52 AM Michael McCandless >> >>>>> >> >> >> >> >> wrote: >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > For a truly "pure" indexing test I usually use a >> single thread for indexing, and SerialMergeScheduler (using that single >> thread to also do single-threaded merging). It makes the indexing take >> forever lol but it produces "comparable" results. >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > But ... this sounds like a great change anyway? >> Do we really need to gate it on benchmark results? Do we think there could >> be a downside e.g. slower indexing on (the dwindling) 32 bit CPUs? >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > Mike McCandless >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > http://blog.mikemccandless.com >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > >> >>>>> >> >> >> >> >> > On Tue, Apr 25, 2023 at 7:39 AM Robert Muir < >> rcm...@gmail.com> wrote: >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> I think the results of the benchmark will depend >> on the properties of >> >>>>> >> >> >> >> >> >> the indexed terms. For english wikipedia >> (luceneutil) the average word >> >>>>> >> >> >> >> >> >> length is around 5 bytes so this optimization may >> not do much. >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> On Tue, Apr 25, 2023 at 1:58 AM Patrick Zhai < >> zhai7...@gmail.com> wrote: >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> > I did a quick run with your patch, but since I >> turned on the CMS as well as TieredMergePolicy I'm not sure how fair the >> comparison is. Here's the result: >> >>>>> >> >> >> >> >> >> > Candidate: >> >>>>> >> >> >> >> >> >> > Indexer: indexing done (890209 msec); total >> 2620 docs >> >>>>> >> >> >> >> >> >> > Indexer: waitForMerges done (71622 msec) >> >>>>> >> >> >> >> >> >> > Indexer: finished (961877 msec) >> >>>>> >> >> >> >> >> >> > Baseline: >> >>>>> >> >> >> >> >> >> > Indexer: indexing done (909706 msec); total >> 2620 docs >> >>>>> >> >> >> >> >> >> > Indexer: waitForMerges done (54775 msec) >> >>>>> >> >> >> >> >> >> > Indexer: finished (964528 msec) >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> > For more accurate comparison I guess it's >> better to use LogxxMergePolicy and turn off CMS? If you want to run it >> yourself you can find the lines I quoted from the log file. >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> > Patrick >> >>>>> >> >> >> >> >> >> > >> >>>>> >> >> >> >> >> >> > On Mon, Apr 24, 2023 at 12:34 PM Thomas Dullien >> wrote: >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >> Hey all, >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >> I've been experimenting with fixing some >> low-hanging performance fruit in the ElasticSearch codebase, and came >> across the fact that the MurmurHash implementation that is used by >> ByteRef.hashCode() is reading 4 bytes per loop iteration (which is likely >> an artifact from 32-bit architectures, which are ever-less-important). I >> made a small fix to change the implementation to read 8 bytes per loop >> iteration; I expected a very small impact (2-3% CPU or so over an indexing >> run in ElasticSearch), but got a pretty nontrivial throughput improvement >> over a few indexing benchmarks. >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >> I tried running Lucene-only benchmarks, and >> succeeded in running the example from >> https://github.com/mikemccand/luceneutil - but I couldn't figure out how >> to run indexing benchmarks and how to interpret the results. >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >> Could someone help me in running the >> benchmarks for the attached patch? >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >> Cheers, >> >>>>> >> >> >> >> >> >> >> Thomas >> >>>>> >> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >> >> - >> >>>>> >> >> >> >> >> >> >> To unsubscribe, e-mail: >> dev-unsubscr...@lucene.apache.org >> >>>>> >> >> >> >> >> >> >> For additional commands, e-mail: >> dev-h...@lucene.apache.org >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >> - >> >>>>> >> >> >> >> >> >> To unsubscribe, e-mail: >> dev-unsubscr...@lucene.apache.org >> >>>>> >> >> >> >> >> >> For additional commands, e-mail: >> dev-h...@lucene.apache.org >> >>>>> >> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> - >> >>>>> >> >> >> >> >> To unsubscribe, e-mail: >> dev-unsubscr...@lucene.apache.org >> >>>>> >> >> >> >> >> For additional commands, e-mail: >> dev-h...@lucene.apache.org >> >>>>> >> >> >> >> >> >> >>> >> >>> >> >>> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- Marcus Eagan

Re: Welcome Chris Hegarty to the Lucene PMC

16 AM Ishan Chattopadhyaya < >>>>> ichattopadhy...@gmail.com> wrote: >>>>> >>>>>> Congratulations Chris! >>>>>> >>>>>> On Mon, 19 Jun, 2023, 3:23 pm Adrien Grand, >>>>>> wrote: >>>>>> >>>>>>> I'm pleased to announce that Chris Hegarty has accepted an >>>>>>> invitation to join the Lucene PMC! >>>>>>> >>>>>>> Congratulations Chris, and welcome aboard! >>>>>>> >>>>>>> -- >>>>>>> Adrien >>>>>>> >>>>>> -- Marcus Eagan

Re: [VOTE] Dimension Limit for KNN Vectors

argument _against_ configurability. Especially in this >>> way -- a toggle that doesn't bind Lucene's APIs in any way. >>> >>> I'll keep this [VOTE] open for a week and then proceed to the >>> implementation. >>> -- >>> *Alessandro Benedetti* >>> Director @ Sease Ltd. >>> *Apache Lucene/Solr Committer* >>> *Apache Solr PMC Member* >>> >>> e-mail: a.benede...@sease.io >>> >>> >>> *Sease* - Information Retrieval Applied >>> Consulting | Training | Open Source >>> >>> Website: Sease.io <http://sease.io/> >>> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter >>> <https://twitter.com/seaseltd> | Youtube >>> <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github >>> <https://github.com/seaseltd> >>> >> -- >> Uwe SchindlerAchterdiek 19, D-28357 Bremen >> <https://www.google.com/maps/search/Achterdiek+19,+D-28357+Bremen?entry=gmail=g>https://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> -- Marcus Eagan

Re: Dimensions Limit for KNN vectors - Next Steps

improvement unambiguously. -1 (non-binding) Marcus Eagan On Tue, May 9, 2023 at 2:49 PM Michael Wechner wrote: > +1 > > Michael Wechner > > Am 09.05.23 um 14:08 schrieb Alessandro Benedetti: > > > *Proposed option*: make the limit configurable > *Motivation*: > The sy

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

gabyte ram buffer can be > >> >> avoided in this way and performance improved by writing bigger > >> >> segments with lucene's defaults. But this doesn't mean we can simply > >> >> ignore the horrors of what happens on merge. merging needs to scale > so > >> >> that indexing really scales. > >> >> > >> >> At least it shouldnt spike RAM on trivial data amounts and cause OOM, > >> >> and definitely it shouldnt burn hours and hours of CPU in O(n^2) > >> >> fashion when indexing. > >> >> > >> >> - > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Marcus Eagan

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

enerate very large and > realistic test vector sets. > > > > > > > > Best regards, > > > > > > > > Kent Fitch > > > > > > > > > > > > On Fri, 7 Apr 2023, 6:53 pm Michael Wechner, < > michael.wech...@wyona.com> wrote: &g

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

>>> > >>>>>>> Anyway. My main point was to remind folks about how Apache works - > >>>>>>> code is merged in when there are no vetoes. If Rob (or anybody > else) > >>>>>>> remains unconvinced, he or she can block the change. (I didn't > invent > >>>>>>> those rules). > >>>>>>> > >>>>>>> D. > >>>>>>> > >>>>>>> > - > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>>>>>> > >>>>>> > - > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>>>>> > >>>>> - > >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>>>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Marcus Eagan

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

; >> > > crashed. Lucene should work with low heap requirements, even if it >>> >> > > slows down. Throwing ram at the indexing/ segment merging problem >>> >> > > is... I don't know - not elegant? >>> >> > > >>> >> > > Anyway. My main point was to remind folks about how Apache works - >>> >> > > code is merged in when there are no vetoes. If Rob (or anybody >>> else) >>> >> > > remains unconvinced, he or she can block the change. (I didn't >>> invent >>> >> > > those rules). >>> >> > > >>> >> > > D. >>> >> > > >>> >> > > >>> - >>> >> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >> > > For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> > > >>> >> > >>> >> > >>> >> > >>> - >>> >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >> > For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> > >>> >> >>> >> - >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> -- Marcus Eagan

Raising the Value of MAX_DIMENSIONS of Vector Values

eed the feedback and the data from the world. Is there something I'm overlooking from a risk standpoint? Best, -- Marcus Eagan

Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

marcussorealheis, marcussorealheis, Marcus Eagan On Sun, Jul 31, 2022 at 7:39 AM Michael McCandless < luc...@mikemccandless.com> wrote: > Thanks, added here: > > https://github.com/apache/lucene-jira-archive/commit/d91534e67b35004f212100d73008283327f2f1e7 > > Please confirm i

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

; colors my view a bit. > > -Gus > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- Marcus Eagan

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

ovation >>> or even usability... and it shows. So I am basically dissatisfied with both >>> (for most of the last 20 years I've been known to mutter about writing my >>> own issue tracker... I've not met one that didn't irritate me somehow, >>> though I haven't actually tried yet, because that's a LOT of work ;) ). >>> >>> Given how many things I've listed, it's likely something's wrong or >>> misapprehended, so certainly speak up if I'm just unaware of something in >>> github. >>> >>> In the end I don't feel like the benefits of github are worth giving up >>> the data quality and features that we do actually use in Jira, so I'm -0.9 >>> on moving to github. >>> >>> -Gus >>> >>> >>> On Fri, May 6, 2022 at 11:11 AM Michael McCandless < >>> luc...@mikemccandless.com> wrote: >>> >>>> On Thu, May 5, 2022 at 7:56 AM Robert Muir wrote: >>>> >>>> As far as replies, in github I highlight the part of the thing i want >>>>> to reply to, and press 'r' key on my keyboard. it quotes it and >>>>> everything. Really convenient to me. >>>>> >>>> >>>> Whoa, thank you!! I had no idea GitHub has such extensive keyboard >>>> shortcuts (just type ? to see them all). >>>> >>>> Mike McCandless >>>> >>>> http://blog.mikemccandless.com >>>> >>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> http://www.the111shift.com (play) >>> >> -- Marcus Eagan

Re: Welcome Guo Feng as Lucene committer

cribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > Anshum Gupta > -- Marcus Eagan

Re: The Retired Open Relevance Project

Makes a lot of sense. I have only seen Anserini in passing. It looks great. I will dig in. Thanks Robert! On Thu, Jan 20, 2022 at 9:18 PM Robert Muir wrote: > On Thu, Jan 20, 2022 at 9:57 PM Marcus Eagan > wrote: > > > > Hi everyone, > > > > Is there anyone

The Retired Open Relevance Project

t went wrong and what it would take to reboot it. Thank you all for your contributions, Marcus Eagan

Re: Revisiting Standardized Test Names in Solr

the statistics on Solr's name >> choice to see if there is a clear winner (e.g. >60%)? I don't have a >> strong opinion on whatever the standard should be so long as there is a >> standard :-) >> >> >> ~ David Smiley >> Apache Lucene/Solr Search Dev

Re: A proposition: Make Luke a standalone package (again)

> > > >>>>> required to do so on LUCENE-9978. > > > >>>>> > > > >>>>> Final note: It doesn't affect ongoing 9.0 release. With the > assemble > > > >>>>> task, Luke works just fine as before. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Tomoko > > > >>>>> > > > >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org > > > >>>>> > > > >>>> > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > >>>> For additional commands, e-mail: dev-h...@lucene.apache.org > > > >>>> > > > >>> > > > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > > > >>> > > > >> > > > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > >> For additional commands, e-mail: dev-h...@lucene.apache.org > > > >> > > > > > > > > -- > > > > Uwe Schindler > > > > Achterdiek 19, 28357 Bremen > > > > https://www.thetaphi.de > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Marcus Eagan

Re: Welcome Peter Gromov as Lucene committer

LanguageTool >> <https://languagetool.org/> and Hunspell, I've also spent some time >> rewriting the latter in Java (here in Lucene), and optimizing them both. In >> my free time, I like mountain hiking (Munich/Germany is a great location >> for that!), and some amateur piano/harmonica playing/singing >> <https://www.youtube.com/user/gromopetr/videos>. >> >>> >> -- Marcus Eagan

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

nd elected Michael Sokolov as the Chair, a >> decision that the board approved in its February 2021 meeting. >> >> Congratulations, Mike! >> >> -- >> Anshum Gupta >> > -- Marcus Eagan

Revisiting Standardized Test Names in Solr

Hi all, Now that Lucene’s standardization is complete and I believe enforced, should we discuss if we could bring the same consistency to Solr? Best, Marcus -- Marcus Eagan

Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!

orm everyone that the newly formed Apache Solr PMC >>> nominated and elected Jan Høydahl for the position of the Solr PMC Chair >>> and Vice President. This decision was approved by the board in its February >>> 2021 meeting. >>> >>> >>> >>> Congratulations Jan! >>> >>> >>> >>> -- >>> >>> Anshum Gupta >>> >> -- > Warm Regards, > > Lucky Sharma > Contact No :+91 9821559918 > -- Marcus Eagan

MongoDB Hosting an Apache Lucene/Solr Meetup

, I'll put out a few dates and meetings invites, and a few optional plans for the broader community to connect with our team and vice versa. Best, -- Marcus Eagan

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

> On Thu, Jan 21, 2021 at 9:21 PM Marcus Eagan > wrote: > >> Hi All, >> >> In looking at the Java Docs, our Lucene team noticed that the `@` symbol >> is a reserved character in the Lucene regular expression syntax. >> >> In re-visiting the page in curio

Is it Time to Deprecate the Legacy Facets API

what you think. If it's a good idea, I will head over to the chopping block. -- Marcus Eagan

Consider Removing the `@` Special Character from RegExp

I suggest we remove `@` from the regular expression syntax. -- Marcus Eagan

Re: Add maxFields Option to IndexWriter

es.apache.org/jira/browse/LUCENE-8909>, there is no way to >> do this without using a reader (which comes with a set of problems >> regarding flush/commit rates). >> >> Would love to add to Lucene the ability to have IndexWriters limiting the >> number of fields. Curious to hear your thoughts. >> >> Thanks, >> Oren >> >> -- Marcus Eagan

Re: [DISCUSS] Cross Data-Center Replication in Apache Solr

e to but wanted to share this as I’m starting > to work on this and wanted to avoid parallel efforts towards the same > end-goal. > > > > -- > > Anshum Gupta > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Marcus Eagan

Re: [Apache Solr] Twitter Account

g posts, without direct commercial purpose, given the fact many >> companies (including mine) make a living out of Apache Solr (but also give >> back to the community in form of blogs and contributions). >> >> >> >> Regards >> > > > -- > Anshum Gupta > -- Marcus Eagan

Re: Maintaining Unnecessary Test Files

them easier to maintain and more flexible. There is another issue, > SOLR-10229, > pertaining to Solr tests ought to configure Solr themselves and rely less > on static test config files, which are a mess to maintain. > > ~ David Smiley > Apache Lucene/Solr Search Developer >

Maintaining Unnecessary Test Files

Hi Community, Lately I have been reading a lot of test files in an attempt to understand what they seek to accomplish. Specifically, what stability and reliability assurance does a given test class provide. In short, I have found some test files that I am unsure are required to provide any of the

Re: Communicating the future of DIH?

e Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless > of whether attachments are marked as such. > > -- Marcus Eagan

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

> [D] >> https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png >> >> Please vote for one of the above choices. This vote will close about one >> week from today, Mon, Sept 7, 2020 at 11:59PM. >> >> Thanks! >> >> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221 >> [first-vote] >> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e >> [second-vote] >> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e >> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting >> > -- Marcus Eagan

Re: Codebase Janitorial Services: the SolrSingleThreaded PR

ate. Solr is a > complex beast that is very hard to understand, so the thought was that we > could start chipping away at it. > > > Mike > > On Wed, Aug 12, 2020 at 1:18 AM Marcus Eagan > wrote: > >> Hi Community, >> >> As I have taken it upon myself

Re: Remove/Replace Nashorn, Remove Eval

we feel we need it, and totally removing eval from the code >> base. It is already mostly removed thanks to work from Kevin and Jan, I >> believe. I wanted to remove it back in March of 2019, but that's another >> story for a different email thread. >> >> Anyway, please advise. >> >> Best, >> >> Marcus Eagan >> >> -- Marcus Eagan

Remove/Replace Nashorn, Remove Eval

thread. Anyway, please advise. Best, Marcus Eagan

Re: First Issue Label

>>> once upon a time with that label and also remember that as something we did >>> at one of the committer meetings, but then the lower hanging JIRAs were >>> really created and resolved without much delay, not leaving much on the >>> table for new developers. &g

Re: Codebase Janitorial Services: the SolrSingleThreaded PR

. I've modified my initial email below to be a bit more focused. Thanks all, Marcus On Tue, Aug 11, 2020 at 11:17 PM Marcus Eagan wrote: > Hi Community, > > As I have taken it upon myself to slowly document opportunities for > improving the overall quality and maintainability of the

Codebase Janitorial Services: the SolrSingleThreaded PR

SingleThreaded actually does that is needed? I have thoughts and have used annotations like this before with Spring, but in my very limited knowledge about what this PR was intended to accomplish, this implementation does nothing. Please advise, Marcus -- Marcus Eagan

Re: RoadMap?

features, and Solr could have its own Roadmap wiki. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> Jan >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> 3. jul. 2020 kl. 09:19 skrev Dawid Weiss : >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >>> I totally expect some things to bubble up when we try to release >>>>> with Gradle, the tarball being one. I don’t think that’s a very big issue, >>>>> but if you have lots of “not very big” issues they do add up. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> Adding a tarball is literally 3-5 lines of code (you add a task >>>>> that builds a tarball or a zip file from the outputs of solr/packaging >>>>> toDir task)... The bigger issue with gradle is that somebody has to step >>>>> up >>>>> and try to identify any other issues and/or missing bits when trying to do >>>>> a full release cycle. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> D. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > -- >>>>> >>>>> >>>>> > - >>>>> >>>>> >>>>> > Noble Paul >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > - >>>>> >>>>> >>>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>> >>>>> >>>>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> - >>>>> >>>>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>> >>>>> >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> http://www.the111shift.com (play) >>> >>> >>> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- Marcus Eagan

Performance in Solr 9 / Java 11

be redundant or irrelevant. Best, -- Marcus Eagan

Re: Standardize Leading Test or Trailing Test

ndardize on something. >>> > This has been brought up before: LUCENE-8626 -- credit to Christine >>> who started the work. I recommend resuming the discussion there. >>> > >>> > ~ David >>> > >>> > >>> > On Thu, Aug 6, 2020 at

First Issue Label

, and in CNCF projects. Please let me know what you think about a first issue label to make it easier for people not necessarily in the community looking to join to do so in the future. Thanks, -- Marcus Eagan

Standardize Leading Test or Trailing Test

rts that I'm working on, but if the community agrees on this one, I can open a ticket and submit a PR. Let me know what you think. Hoping to make the project more developer friendly. -- Marcus Eagan

Re: SolrClient and making requests asynchronously

plementation can allow > users to handle the behaviour of timeout and other events. We should retain > that behaviour. > -- > Regards, > > Atri > Apache Concerted > -- Marcus Eagan

Re: Deprecate Schemaless Mode?

Typo*, I meant deprecate vs. remove, which obviously cannot do. On Mon, Aug 3, 2020 at 12:05 Marcus Eagan wrote: > Furthermore, just to be clear, I opened a discussion about deprecating and > not replacing schemaless mode for two reasons: > > (1) the pain it has inflicted o

Re: Deprecate Schemaless Mode?

es offense to me challenging how some community members think about what is a good feature vs what is a bad one. Marcus On Mon, Aug 3, 2020 at 11:44 AM Marcus Eagan wrote: > I know a person using it in production today. It's causing problems. They > could abandon Solr altogether. It see

Re: Deprecate Schemaless Mode?

e used. >> Disable them by default (where that makes sense). Taken to the >> extreme, we could even add a section into Solr's response that lists >> non-production features used in serving a given request. >> >> There are lots of ways to address the "feature X

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

Atri Sharma : >> > >> > +1 >> > >> > SUCCESS! [1:27:33.14892] >> > >> > On Mon, Aug 3, 2020 at 1:11 PM Marcus Eagan >> wrote: >> >> >> >> Community, >> >> >> >> Results from my local smoke

Deprecate Schemaless Mode?

tps://issues.apache.org/jira/browse/SOLR-14701?> Thank you all, Marcus Eagan

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

want an additional >>> business day, but will end it on Monday otherwise. >>> > >>> > - Houston >>> > >>> > >>> > >>> > On Thu, Jul 30, 2020 at 5:07 PM Houston Putman < >>> houstonput...@gmail.com> wrote: >>> >> >>> >> Please vote for release candidate 1 for Lucene/Solr 8.6.1 >>> >> >>> >> The artifacts can be downloaded from: >>> >> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2 >>> >> >>> >> 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.6.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2 >>> >> >>> >> The vote will be open for at least 72 hours i.e. until 2020-08-02 >>> 22:00 UTC. >>> >> >>> >> [ ] +1 approve >>> >> [ ] +0 no opinion >>> >> [ ] -1 disapprove (and reason why) >>> >> >>> >> Here is my +1 >>> >>> >>> >>> -- >>> - >>> Noble Paul >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- Marcus Eagan

Re: 8.6.1 Release

gt;>>>>>>>>>>> Absolutely, Ilan! Good idea. I initially hesitated in >>>>>> doing so because Andrzej had a workaround in mind for them, so I thought >>>>>> it >>>>>> would be better if he did this. But, it makes sense to inform them of the >>>>>> issue right away anyway. >>>>>> >>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>> On Wed, 22 Jul, 2020, 11:42 pm Ilan Ginzburg, < >>>>>> ilans...@gmail.com> wrote: >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> Shouldn't we add a note right away to 8.6 notifying >>>>>> of the issue? >>>>>> >>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>> Le mer. 22 juil. 2020 à 20:08, Atri Sharma < >>>>>> a...@apache.org> a écrit : >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> +1, thanks Houston. >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> On Wed, Jul 22, 2020 at 10:51 PM Houston Putman < >>>>>> houstonput...@gmail.com> wrote: >>>>>> >>>>>>>>>>>>>>>>> > >>>>>> >>>>>>>>>>>>>>>>> > If we agree that this warrants a patch release, I >>>>>> volunteer to do the release. >>>>>> >>>>>>>>>>>>>>>>> > >>>>>> >>>>>>>>>>>>>>>>> > I do think a patch release is reasonable even if >>>>>> users have to take an action when upgrading from 8.6.0. I imagine most >>>>>> users haven't upgraded to 8.6.0 yet, so if we make the patch now we will >>>>>> make life easier for everyone that upgrades between now and when 8.7 is >>>>>> released. >>>>>> >>>>>>>>>>>>>>>>> > >>>>>> >>>>>>>>>>>>>>>>> > On Wed, Jul 22, 2020 at 12:50 PM Atri Sharma < >>>>>> a...@apache.org> wrote: >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >> Ignore this, I misread your email. >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >> On Wed, Jul 22, 2020 at 9:11 PM Atri Sharma < >>>>>> a...@apache.org> wrote: >>>>>> >>>>>>>>>>>>>>>>> >> > >>>>>> >>>>>>>>>>>>>>>>> >> > Should we not revert the change so that users >>>>>> upgrading from 8.6 to >>>>>> >>>>>>>>>>>>>>>>> >> > 8.6.1 get the earlier default policy? >>>>>> >>>>>>>>>>>>>>>>> >> > >>>>>> >>>>>>>>>>>>>>>>> >> > On Wed, Jul 22, 2020 at 9:09 PM Houston Putman >>>>>> wrote: >>>>>> >>>>>>>>>>>>>>>>> >> > > >>>>>> >>>>>>>>>>>>>>>>> >> > > +1 >>>>>> >>>>>>>>>>>>>>>>> >> > > >>>>>> >>>>>>>>>>>>>>>>> >> > > Question about the change. Since this patch >>>>>> added a default autoscaling policy, if users upgrade to 8.6 and then >>>>>> 8.6.1, >>>>>> does the default autoscaling policy stay once they have upgraded? If so >>>>>> we >>>>>> probably want to include instructions in the release notes on how to fix >>>>>> this issue once upgrading. >>>>>> >>>>>>>>>>>>>>>>> >> > > >>>>>> >>>>>>>>>>>>>>>>> >> > > - Houston >>>>>> >>>>>>>>>>>>>>>>> >> > > >>>>>> >>>>>>>>>>>>>>>>> >> > > On Wed, Jul 22, 2020 at 1:53 AM Ishan >>>>>> Chattopadhyaya wrote: >>>>>> >>>>>>>>>>>>>>>>> >> > >> >>>>>> >>>>>>>>>>>>>>>>> >> > >> Hi, >>>>>> >>>>>>>>>>>>>>>>> >> > >> There was a performance regression >>>>>> identified in 8.6.0 release due to SOLR-12845. I think it is serious >>>>>> enough >>>>>> to warrant an immediate bug fix release. >>>>>> >>>>>>>>>>>>>>>>> >> > >> >>>>>> >>>>>>>>>>>>>>>>> >> > >> I propose a 8.6.1 release. Unfortunately, >>>>>> I'll be unable to volunteer for this release owning to some other >>>>>> commitments, however Andrzej mentioned in Slack that he might be able to >>>>>> volunteer for this post 27th. >>>>>> >>>>>>>>>>>>>>>>> >> > >> >>>>>> >>>>>>>>>>>>>>>>> >> > >> Are there any thoughts/concerns regarding >>>>>> this? >>>>>> >>>>>>>>>>>>>>>>> >> > >> Regards, >>>>>> >>>>>>>>>>>>>>>>> >> > >> Ishan >>>>>> >>>>>>>>>>>>>>>>> >> > >>>>>> >>>>>>>>>>>>>>>>> >> > -- >>>>>> >>>>>>>>>>>>>>>>> >> > Regards, >>>>>> >>>>>>>>>>>>>>>>> >> > >>>>>> >>>>>>>>>>>>>>>>> >> > Atri >>>>>> >>>>>>>>>>>>>>>>> >> > Apache Concerted >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >> -- >>>>>> >>>>>>>>>>>>>>>>> >> Regards, >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >> Atri >>>>>> >>>>>>>>>>>>>>>>> >> Apache Concerted >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> - >>>>>> >>>>>>>>>>>>>>>>> >> To unsubscribe, e-mail: >>>>>> dev-unsubscr...@lucene.apache.org >>>>>> >>>>>>>>>>>>>>>>> >> For additional commands, e-mail: >>>>>> dev-h...@lucene.apache.org >>>>>> >>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> -- >>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> Atri >>>>>> >>>>>>>>>>>>>>>>> Apache Concerted >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>>>>>>> >>>>>> - >>>>>> >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: >>>>>> dev-unsubscr...@lucene.apache.org >>>>>> >>>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>> dev-h...@lucene.apache.org >>>>>> >>>>>>>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> -- >>>>>> >>>>>>>>>>>> http://www.needhamsoftware.com (work) >>>>>> >>>>>>>>>>>> http://www.the111shift.com (play) >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> -- >>>>>> >>>>>>>>>> http://www.needhamsoftware.com (work) >>>>>> >>>>>>>>>> http://www.the111shift.com (play) >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>>>> >>>>>>>>> -- >>>>>> >>>>>>>>> http://www.needhamsoftware.com (work) >>>>>> >>>>>>>>> http://www.the111shift.com (play) >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> http://www.needhamsoftware.com (work) >>>>>> >>>>> http://www.the111shift.com (play) >>>>>> >>>> >>>>>> >>>> >>>>>> >>>>>> >>>>>> -- >>>>>> - >>>>>> Noble Paul >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> >>>>>> -- >>>> Regards, >>>> >>>> Atri >>>> Apache Concerted >>>> >>> -- Marcus Eagan

Re: [VOTE] Solr to become a top-level Apache project (TLP)

ity is invited to > > express their opinion, though only Lucene+Solr committers cast binding > > votes (indicate non-binding votes in your reply, please). > > > > The vote will be active for a week to give everyone a chance to read > > and cast a vote. > > > > Dawid > > > > [1] https://www.apache.org/foundation/voting.html > > [2] > https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Marcus Eagan

Re: Solr Admin UI Refresh 2020

hem: does react or vue have the equivalent > of ng serve? It's nice to be able to iterate the ui quickly. That's one > thing I do like about it. > > > https://www.udemy.com/blog/react-js-vs-angular-vs-vue-js-which-is-the-best-javascript-framework/ > > -Gus > > On Thu, Apr 23, 20

Re: Solr Admin UI Refresh 2020

- More moving parts, separate releases, more bureaucracy > - May be a problem to obtain enough PMC members vote (ask Andi), need a > separate smoketester? > - UI is not tested as part of Solr, breaking changes may be merged > unnoticed. (This can be mitigated with e2e Jenkins tests)

Re: Solr Admin UI Refresh 2020

> > > On Wed, Apr 22, 2020 at 12:14 PM Marcus Eagan > wrote: > >> Parity is not necessarily a good thing. Maintaining most of the existing >> functionality is good. I would recommend some of it is removed because it’s >> dangerous. >> >> My choice t

Re: Solr Admin UI Refresh 2020

the code. Happy to support, looking for input. Singular goal in my mind - replace current UI for safety of users, especially new ones. Thanks, On Wed, Apr 22, 2020 at 9:14 AM Marcus Eagan wrote: > Parity is not necessarily a good thing. Maintaining most of the existing > functionality i

Re: Solr Admin UI Refresh 2020

>>> >> >>> WRT legal aspect, the original git repo >> https://github.com/savantly-net/solr-admin does not say anything about >> copyright or license. I encourage you to reach out to the copyright holder >> to let them/him know about your intentions and get a

Re: Solr Admin UI Refresh 2020

this much needed SIP to bog down on a technical issue. > > -Gus > > On Mon, Apr 20, 2020 at 7:10 AM Jan Høydahl wrote: > >> Please retry. I gave edit access to confluence user id ‘marcussorealheis’. >> >> Jan >> >> 20. apr. 2020 kl. 01:30 skrev Marcus Eagan :

Re: Solr Admin UI Refresh 2020

neeed that SIP, do you still need help > with Confluence? > > Jan Høydahl > > 19. apr. 2020 kl. 06:30 skrev Marcus Eagan : > >  > I hope everybody is enjoying their weekend and is in good health. > > Filed a Jira, made a PR: https://issues.apache.org/jira/browse/SOLR-14

Re: Solr Admin UI Refresh 2020

with time, some involvement from a few Angular wizards, and a bit of research. Thank you everyone, Marcus On Tue, Apr 14, 2020 at 2:01 PM Marcus Eagan wrote: > > Gus, At first it looked like it let me, but today it seemed that it did > not allow me to create a SIP. > > > >

Re: Solr Admin UI Refresh 2020

; > @Marcus can you confirm that you tried to create a page, it appeared to > let you and then threw out your work on submission? (or am I reading what > you wrote wrong?) > -- Marcus Eagan

Re: Solr Admin UI Refresh 2020

> that are not problematic (if anyone is so inclined to work on those). > > Hopefully you don’t mind the unsolicited advice on this, just trying to > help you understand some of our ways of doing things. > > Cassandra > On Apr 14, 2020, 3:18 AM -0500, Marcus Eagan , > wrote:

Re: Solr Admin UI Refresh 2020

uld be challenging for anyone. This project, like all project, has some skeletons. From my perspective, that's gfreat because there are lots of things to improve. Also, the project is still pretty amazing. Thanks again for your help everyone, Marcus On Mon, Apr 13, 2020 at 9:55 AM Marcus Eagan wr

Re: Solr Admin UI Refresh 2020

ts for some folks, can you upload the >> video somewhere else and link to it for us poor unfortunate souls? Thanks >> for your work! Excited to see the progress as it happens. >> >> Mike >> >> On Mon, Apr 13, 2020 at 5:30 AM Marcus Eagan >> wrote: >

Re: Solr Admin UI Refresh 2020

odebase, where it currently is. The reason is, we can't fix > bugs if we break something. We don't have automated testing either to know > whether or not we broke anything. > > Every healthy project has a rich plugin ecosystem, and such non core > improvements should be delivere

Re: Solr Admin UI Refresh 2020

ing, > without the user having to take any additional steps whatsoever. As Jan > said it's been this way a long time. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Apr 10, 2020 at 1:35 AM Marcus Eagan

Re: Solr Admin UI Refresh 2020

in unusual ways from the needs of commercial web development. > > >>> > > >>> -Gus > > >>> > > >>> On Thu, Apr 9, 2020 at 8:14 AM Erick Erickson < > erickerick...@gmail.com> wrote: > > >>> Marcus: > > >>> > &g

Re: Solr Admin UI Refresh 2020

MVC/REST style... > > So there's another $0.02 :) and if you're not careful I'll give you an > entire nickle's worth of ways people misuse/misunderstand the term REST :) > > -Gus > > On Tue, Apr 7, 2020 at 9:06 PM Marcus Eagan wrote: > >> Gus, >> >> Your

Re: Solr Admin UI Refresh 2020

s to > butcher then NOW is the time to be up front about what some of the most > opinionated amongst us can accept. > > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Tue, Apr 7, 2020 at 9:06 PM Marcus Eaga

Re: Solr Admin UI Refresh 2020

productive >> with the UI code, that would be a win. On the other hand, if we expect that >> the UI will be maintained by regular Java committers, then anything that >> makes it easier for them/us to contribute is also a win, like perhaps >> strongly-typed. &

Re: Solr Admin UI Refresh 2020

apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Marcus Eagan

Solr Admin UI Refresh 2020

Coming back to these existential questions from my phone: *Jan Høydahl* Added 1 hour ago There are many opinions around admin UI. So I think the best place to start would be a new mail-thread in dev@ to discuss the way forward. Before we start a major re-work, we should probably ask

Re: Migrate Solr helm chart into apache/lucene-solr repo

e: > >> Hi, >> >> >> >> Since helm stable repo is deprecated, it’s taking a lot of time to get >> the pull requests approved. >> >> Also the helm chart for Solr has to go somewhere soon, refer to >> https://github.com/helm/charts#deprecation-timeline. >> >> >> >> Would you guys be adopting it? >> > -- Marcus Eagan

Re: Maintenance of Solr's official Dockerfile

lish the images, we just > initiate it… > Do we know any other ASF project that maintain their own official > docker image? > 4. Practical things - change README, NOTICE, header files, wording etc > > I have opened https://issues.apache.org/jira/browse/SOLR-14168 as an > umbrella issue for tasks that spin out from this email thread discussion. > > Jan Høydahl > -- Marcus Eagan

Re: Change solr/lucene Readme file format

Most README files in contemporary open source projects are Markdown because of the formatting features. I personally favor convention over ease of use in this case. Marcus Eagan On Sun, Nov 10, 2019, 8:58 AM Erick Erickson wrote: > Personally I’d make them text files. The last thing I w

[jira] [Updated] (SOLR-13737) Lead with SolrCloud

[ https://issues.apache.org/jira/browse/SOLR-13737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-13737: Status: Patch Available (was: Open) > Lead with SolrCl

[jira] [Updated] (SOLR-13737) Lead with SolrCloud

[ https://issues.apache.org/jira/browse/SOLR-13737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-13737: Status: Open (was: Patch Available) > Lead with SolrCl

[jira] [Created] (SOLR-13737) Lead with SolrCloud

Marcus Eagan created SOLR-13737: --- Summary: Lead with SolrCloud Key: SOLR-13737 URL: https://issues.apache.org/jira/browse/SOLR-13737 Project: Solr Issue Type: Improvement Security Level

[jira] [Comment Edited] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914342#comment-16914342 ] Marcus Eagan edited comment on SOLR-13649 at 8/23/19 3:22 PM: -- bq. What I

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914342#comment-16914342 ] Marcus Eagan commented on SOLR-13649: - bq. What I was hoping for wrt smooth upgrade was a way to make

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911042#comment-16911042 ] Marcus Eagan commented on SOLR-13649: - for people watching this issue, I have added the appropriate

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905973#comment-16905973 ] Marcus Eagan commented on SOLR-13649: - My apologies. I thought that an error was what you were

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905822#comment-16905822 ] Marcus Eagan commented on SOLR-13649: - I've added an error in case the blockUnknown parameter

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897572#comment-16897572 ] Marcus Eagan commented on SOLR-13649: - [~noble.paul] That makes sense. It will be only added to 9.0

[jira] [Commented] (SOLR-13649) BasicAuth's 'blockUnknown' param should default to true

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897554#comment-16897554 ] Marcus Eagan commented on SOLR-13649: - [~noble.paul] Can you explain what's backward incompatible

[jira] [Updated] (SOLR-13649) When Using Basic Authentication, the blockUnknown Value should be True

[ https://issues.apache.org/jira/browse/SOLR-13649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-13649: Fix Version/s: master (9.0) > When Using Basic Authentication, the blockUnknown Value sho

[jira] [Created] (SOLR-13649) When Using Basic Authentication, the blockUnknown Value should be True

Marcus Eagan created SOLR-13649: --- Summary: When Using Basic Authentication, the blockUnknown Value should be True Key: SOLR-13649 URL: https://issues.apache.org/jira/browse/SOLR-13649 Project: Solr

[jira] [Comment Edited] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870715#comment-16870715 ] Marcus Eagan edited comment on SOLR-13537 at 6/24/19 1:02 AM: -- Build badges

[jira] [Commented] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870715#comment-16870715 ] Marcus Eagan commented on SOLR-13537: - Build badges won’t be dynamic in a forked repo because

Re: [jira] [Commented] (SOLR-13537) Build Status Badge in git README

Issue Type: Wish > > Security Level: Public(Default Security Level. Issues are Public) > > Components: Build, documentation > >Affects Versions: master (9.0), 8.2 > >Reporter: Marcus Eagan > >Priority: Trivial > > Att

[jira] [Commented] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869929#comment-16869929 ] Marcus Eagan commented on SOLR-13537: - [~janhoy] Good idea Jan. I've updated the PR and added

[jira] [Updated] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-13537: Attachment: Single Line Badges.png > Build Status Badge in git REA

[jira] [Comment Edited] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865229#comment-16865229 ] Marcus Eagan edited comment on SOLR-13537 at 6/17/19 1:37 AM: -- [~elyograg] I

[jira] [Commented] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865229#comment-16865229 ] Marcus Eagan commented on SOLR-13537: - [~elyograg] I was using the Solr artifact so I put

[jira] [Updated] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-13537: Attachment: Simple Artifact Build Badges.png > Build Status Badge in git REA

[jira] [Commented] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864642#comment-16864642 ] Marcus Eagan commented on SOLR-13537: - [~janhoy] I don't know if you saw, but I added a new badge

[jira] [Comment Edited] (SOLR-13537) Build Status Badge in git README

[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864185#comment-16864185 ] Marcus Eagan edited comment on SOLR-13537 at 6/14/19 3:25 PM: -- I added a new

  1   2   >