Pardon my vagueness in this question, it's client technology that I can't
reveal too many details about...
In the docs I see:
- Tokens that have the same start position must have the same start
offset.
- Tokens that have the same end position (taking into account the
position length)
Welcome, Armin!
On Mon, Jul 29, 2024 at 2:14 AM Stefan Vodita
wrote:
> Welcome, Armin!
>
> On Thu, 25 Jul 2024 at 12:08, Luca Cavanna wrote:
>
>> I'm pleased to announce that Armin Braun has accepted the PMC's
>> invitation to become a Lucene committer.
>>
>> Armin, the tradition is that new co
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
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!
>
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 Proje
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
d
>> such possibly helpful history?
>>
>> 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 can
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
som
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
>
found 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 spe
same jar 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:
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:
>>
>>> > Having
th
> some ideas to at least improve cpu usage by a factor of N. It does not help
> with the 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
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,
tps://github.com/apache/lucene/issues/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
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.
>
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 that's
gt;> wrote:
>> >
>> > sorry - 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
tests 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, g
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 si
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 d
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 w
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 makin
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 this
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 topic,
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:
>>
>>> Th
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
>
&
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 threa
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:11 PM
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 (e.g.
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 Luc
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 to
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,
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 ol
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 and
+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
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 se
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 accep
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
>
> Con
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
>
>
> *Sease*
-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.
W
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 :
>
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
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
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 as
ibute to
>>>>the project?
>>>>- Which fits into the workflows of existing committers the best?
>>>>
>>>> To me Github comes up on top, even though there are things that JIRA
>>>> does better.
>>>>
>>>> P.S. I
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 a
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, 20
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
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
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
res
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...
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
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 wrot
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 han
e security
> mailing list.
>
> 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 <
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 t
+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 think
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", userInpu
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:
>
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
> wro
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
> fo
stopper. This applies 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
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 f
+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 eve
;>>>>
>>>>>
>>>>> 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!
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
th
+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: thelabdude/apache-solr-dev:8.1
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!
>>
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 4
t; > Thanks 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:
> >>
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
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
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 accepte
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
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 Anshum
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 foundation-wid
ward to a standardization on *something* but would prefer that
> 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 f
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
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 control
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.
as it 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
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
--
http://www.nee
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 r
>
> 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 mainta
+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
>
>
>
> 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 bei
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 machi
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 t
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 in
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 certainly
+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 8
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 Houston!
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!
>>
>>
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 t
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 con
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 dat
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
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 bigg
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 related
1 - 100 of 1000 matches
Mail list logo