Just a simple +1 of support to modernization efforts in general. It's
encouraging to see that Jason & Eric had some fun together on this.
Modernization, I think, helps with the fun of any open-source project, and
thus helps keep everyone interested in continuing and reviewing interest in
Solr. If
Thanks for the heads-up!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Dec 1, 2021 at 12:05 PM Adrien Grand wrote:
> Hello Solr devs,
>
> This is a heads up that the BadApple annotation has been removed from
> Lucene 10.x sin
has concerns that I shouldn't do this now then let me know.
[1] https://github.com/docker-solr/docker-solr/pull/396
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
#apache-solr-affected-by-apache-log4j-cve-2021-44228
[2] https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
n
to raise undue alarm bells. Maybe we should remove it.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
Looks good; thanks Jan!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Dec 13, 2021 at 9:34 AM Jan Høydahl wrote:
> Including Lucene dev as well.
>
> As I see no Lucene level bug fixes for 8.11.1, I have prepared an "em
Correct. I just reviewed occurrences of log.info, log.warn etc. and it's
all boring stuff that definitely doesn't take user input.
I'm going to remove this from the news in my PR:
https://github.com/apache/solr-site/pull/54
~ David Smiley
Apache Lucene/Solr Search
I created a new one actually: https://github.com/apache/solr-site/pull/55
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Dec 13, 2021 at 7:39 PM David Smiley wrote:
> Correct. I just reviewed occurrences of log.info, log.warn etc. and i
gine some new request handler that allows you to
provide this key & query and have it perform a filter cache save,
overwriting whatever entry that may have been there. You could even do
this in a newSearcher event on the inventory core, calling into the primary
product core.
~ D
a dev vs prod mode to gate better
defaults but no action there yet :-/.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Dec 17, 2021 at 5:22 PM Marcus Eagan wrote:
> Hi,
>
> As a part of the Log4j madness we all have dealt with, I l
edited" puts us in a
position where we have to acknowledge this word on their part and defend
ourselves so it's clear our guidance came out *after* there's, and that we
are confident.
Yes and link to the Wiki's discredited list; linking to it. I'll get on
that.
~ David Sm
Going right to 9.1 averts issues there for Solr users writing
plugins.
You're right RE blockers -- it's always tough to let go of our
ideals/hopes/dreams on what we want 9.0 to be.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Dec 21
a SIP anyway -- forcing a discussion on major decisions.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Dec 22, 2021 at 10:36 PM Marcus Eagan wrote:
> It doesn't seem that bad, yet I know some people will freak. According to the
&
Users have a valid mitigation that is easy to apply (that sys prop =true),
and they could upgrade Log4j themselves if they are extra paranoid (e.g.
corp mandates, which I am familiar with). So I think no further action by
our project is necessary.
(Merry Christmas to you all)
On Fri, Dec 24, 202
I completely agree with Houston; let's not create branch_9_0 yet.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Jan 3, 2022 at 11:36 AM Houston Putman
wrote:
> I think its fine to start with just branch_9x until we are ready to
&g
visit only the
matching docs but that would add complexity.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Jan 3, 2022 at 2:30 PM Daniele Antuzi
wrote:
> Hi Mikhail,
> Thanks for your reply.
> Probably I wasn't clear enough, actual
are
omitted yet the many older ones exist.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Jan 4, 2022 at 4:01 PM Houston Putman wrote:
> Dawid,
>
> I did mean that we should be pushing the tags as well as their associated
> comm
Removing the old tags is valid too. But the current state is
confusing/inconsistent and something should be done. Thanks for raising
this Houston.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jan 6, 2022 at 8:56 AM Uwe Schindler wrote
I'm aware our nifty image building enables people to do a custom build to
specify their own preferred FROM image, which is cool. Still, I think we
should move on to 17 as the default.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
It's as much about
optics as anything. I think many users are probably more at a curiosity /
exploratory stage with this topic but still -- Solr 9 without the ability
to explore this is disappointing, leaving them to consider other options to
scratch that itch.
~ David Smiley
Apache Lucene/S
roposal to move to Java 17 at this juncture)
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jan 6, 2022 at 4:03 PM David Smiley wrote:
> I'd like to propose that our Docker image for Solr 9 move from Java 11 to
> Java 17. Admitt
me to look at this is that there is some time spent
registering and unregistering SolrCore level metrics to JMX when SolrCores
are loaded and unloaded, and logs to this effect likewise. Not a big deal
but it's something.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
ve a strong opinion there.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Jan 10, 2022 at 10:22 AM Matthias Krueger wrote:
> JMX has its issues but we should be aware that it currently provides a
> relatively generic and easy to use integr
a "real" release that may not have all of
the changes we want to make yet -- be they cool things like vector search
or backwards-incompatible changes. It could also give us a reasonable
excuse to ship some features and have them be refined subsequently.
~ David Smiley
Apache Lucene/Solr S
orldclock/fixedtime.html?msg=Solr+Committer+Meeting&iso=20220120T11&p1=43&ah=1
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
Woops; wrong URL. I meant what I said -- noon EST.
Correct URL
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Solr+Committer+Meeting&iso=20220120T12&p1=43&ah=1
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Jan 11, 202
isn't allowed by the Lucene's test SecurityManager that
we're using. The relevant code was recently touched by Jan but the
System.exit's have been there for a while.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
All awesomeness!
Speaking of modularization:
* https://issues.apache.org/jira/browse/SOLR-15904 Move SQLHandler to a
contrib/module/package
-- just a JIRA issue; I don't have time for this one now.
* https://issues.apache.org/jira/browse/SOLR-14660
~ David Smiley
Apache Lucene/Solr S
https://issues.apache.org/jira/browse/SOLR-15342 "Separate out a
SolrJ-Zookeeper module" -- I'm working with a colleague on this one. I
anticipate something by the end of the week.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Jan
need to
add a Dockerfile and to publish it. The beauty of this is that it can have
its own release cycle! That means very few releases in practice. Although
it means extra work for actually doing these releases (voting,
release-manager steps, publishing), instead of a free ride on the Solr
release
act that is
published? I'm not sure what freedoms we have to do this in the ASF.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Jan 12, 2022 at 8:21 PM Shawn Heisey wrote:
> On 1/12/2022 8:31 AM, Jan Høydahl wrote:
> > I think
hread/jbs4ds0w3r3v1hto9rqhs4qq1xfk5z61
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sun, Jun 13, 2021 at 7:31 AM Jan Høydahl wrote:
> When we collapse the solr/solr structure I hope we can keep the number of
> top-level folders in git to a minimum. There are too many
ople use in general.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jan 13, 2022 at 10:59 AM Houston Putman wrote:
> It could very well be worth shipping two docker images in the meantime.
>> Or maybe a zip of each module could be a se
I created a wiki page for the meeting:
https://cwiki.apache.org/confluence/display/SOLR/2022-01-20+Meeting+notes
I propose that we try and keep this meeting to one topic: 9.0, which is big
because it's any changes to discuss that may/may-not make 9.0. The meeting
release cadence will increase so
7
* https://issues.apache.org/jira/browse/SOLR-14660 HDFS (or Hadoop?)
-- Waiting for the contributor to return to it. See the issue for
discussion on what to do if it stagnates further.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
ultimately the same path to the data that
exists today. But since SOLR_HOME stays with Solr, so does the lib and
thus it's easy to mount in some other path or whatever.
I didn't create a JIRA issue... I've been extremely busy. But before I do,
WDYT about this?
~ David Smiley
Fair points. I might take a stab at this on the weekend to see.
I propose no change to the SOLR_HOME detection logic, which will naturally
end up being SOLR_INSTALL/server/solr (where solr.xml is). Docker stuff
won't need to set it / play games as it does now.
~ David Smiley
Apache Lucene
I was merely listing PRs I was working on or closely related to; not an
exclusive list to those others are working on :-)
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Jan 14, 2022 at 12:45 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.
ould even have MiniSolrCloudCluster or Jetty Solr runner thing do a
test runtime look to see if the current test is classified as an
integration test, and fail otherwise. Just an idea to help us enforce use
of this correctly.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.co
for it
to not just have configuration but data as well depending on how someone
configures/uses it.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jan 13, 2022 at 11:27 AM Houston Putman wrote:
> So would make sense to move configsets out to $
r the next year. Oh well, I guess.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Jan 14, 2022 at 2:59 PM Jan Høydahl wrote:
> Thanks for being so structured and transparent about your proposals,
> David. I'll not comment on each JIRA
ng two
Solr plugins:
* HadoopAuthPlugin
* KerberosPlugin
Are we okay with expanding the scope of SOLR-14660 to include these?
Note that SOLR-14660 *might* result in 9.0 not including this module in the
release distribution if we don't feel the module will be sufficiently ready
to release.
~ David Smiley
A
implementation ('org.apache.hadoop:hadoop-annotations')
runtimeOnly 'org.apache.htrace:htrace-core4' // note: removed in Hadoop 3.3.2
runtimeOnly "org.apache.commons:commons-configuration2"
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/d
there's an existing thread that can be
re-awoken.
I'll bring up the scheduling/organizing of the next meeting in a new thread
now so that it isn't forgotten.
It was great to hear all the peer-to-peer complements at the end. If I
could have kept the meeting going, we could have kep
there are no requests for this, I propose we at
least move the next meeting to one hour earlier than previously to make it
a little nicer for Europe timezones. Pacific can wake up at 8am --
personally I wake up at 6:40am every day :-)
[1]: https://projects.apache.org/committee.html?solr
~ David
I posted a JIRA issue & PR: https://issues.apache.org/jira/browse/SOLR-15944
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sun, Aug 29, 2021 at 3:13 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:
> Bas
Now is a great time to do some name changes. I suggest that you make a
specific proposal of what the names should be.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Jan 21, 2022 at 8:18 AM Alessandro Benedetti
wrote:
> I would also ad
mes on
bin/solr at startup.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Jan 21, 2022 at 8:55 AM Jan Høydahl wrote:
> There was a message from Alessandro in another thread
> <https://lists.apache.org/thread/q014rj1o4cnhq6olr3krnm66q448
+1 I like your proposed names. Some of our names are so short now that
only us know what they are at a glance.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Jan 21, 2022 at 11:01 AM Jan Høydahl wrote:
> There is kind of a proposal
There is an alternative approach to achieve the aims here, which I think is
a bit simpler. No SOLR_VAR env; we don't need it. Instead SOLR_HOME is
that. Anything that goes in SOLR_HOME would be resolved with defaulting
logic off of SOLR_TIP (solr install dir) at the typical paths from there
(e.g
SOLR-15064 "Atomic/partial updates to nested docs should not assume _route_
param is the root ID" will be simple; I will do it.
RE the UH being the default; I'm about to post a PR
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sat,
Yes; I was thinking something like this as well. This way we can make
meaningful progress on modularization during the 9x series without breaking
compatibility.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sat, Jan 29, 2022 at 4:37 PM Jan
ould need to be reconciled with the package
manager's approach.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Jan 31, 2022 at 6:01 AM Jan Høydahl wrote:
> Could this work? :
>
> Say, in 9.1 that we move feature FOO out of core into a
This is a nice fresh look; thanks Cassandra, Houston, and Mike!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Feb 10, 2022 at 12:47 PM Houston Putman wrote:
> Hey everyone. The new ref guide is officially merged into all relevant
> br
OMG I see we have search now -- good search with snippets too! How does it
work?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Feb 10, 2022 at 1:09 PM David Smiley wrote:
> This is a nice fresh look; thanks Cassandra, Houston, and M
Closing the loop here: https://issues.apache.org/jira/browse/SOLR-15949 for
Java 17 via the Eclipse Temurin distribution. I'll merge this weekend.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sun, Jan 9, 2022 at 3:01 AM Mark Miller
When I do "gw check", I see an error about a a "npx" program not being
found:
> Process 'command
> '/Users/dsmiley/SFDCDev/solr_main/.gradle/node/nodejs/node-v16.13.2-darwin-x64/bin/npx''
> finished with non-zero exit value 1
>
Um... are there new prerequisites to do a build? Is this documented?
reads the CHANGES.txt
to read that some test doesn't need a dependency it once needed ;-).
Fundamentally ask yourself *who cares*? Are there user perceivable
consequences? Are there non-trivial risks?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
O
Hi Raveesh!
Have you thought of participating in Google Summer of Code or similar
programs?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sun, Feb 20, 2022 at 11:04 PM Raveesh Gupta
wrote:
> Hi,
>
>> My name is Raveesh Gupt
th non-zero exit value 1
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1m 20s
I would appreciate any help! Maybe we might use
took a
bit of doing "git worktree repair LINKNAME" to my linked checkouts to
re-establish the links bidirectionally.
Thanks Houston for some pointers!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Feb 22, 2022 at 2:08 PM David Sm
at least a sanity check
(no errors) for the prometheus exporter default config. I think this is a
release blocker. I'm putting this aside now but perhaps someone knows what
happened to it?.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Mar 1, 2022 at 4:46 AM Jan Høydahl wrote:
> Hi, and welcome to March!
>
> Our initial goal of a RC1 within February slipped, but we are still in a
> good position.
> I'll try to summarize the current code blockers:
>
>
> *SOLR-16061 Decouple CloudSolrClient from ZkStateReader*
>
> This i
andler so much that I prefer to present it as its
own identity from a metrics standpoint.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Mar 1, 2022 at 4:19 PM Timothy Potter wrote:
> Hi David,
>
> I read your note about SOLR-14401 but
fferent factories/builder?
>
How is the contract between CloudSolrClient & BaseCloudSolrClient different
Jan? I suspect if there's breakage, it'd be relatively obscure options on
the builder.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
; code would continue to work..
>
Hey, this is a major release; let's not hold ourselves to a standard that
is too onerous for us to maintain. We can make our intentions clear in
upgrade notes.
~ David
> Jan
>
>
> 14. mar. 2022 kl. 15:40 skrev David Smiley :
>
>
or
version?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Mar 16, 2022 at 4:53 PM Jason Gerlowski
wrote:
> > We can only hypothesize _why_ a client is dependent in the first place
> ... Perhaps to tweak/tune advanced options, ti
nt
or CloudHttp1SolrClient but I lean to keep CloudSolrClient and do a bit of
casting on occasion when necessary (e.g. to access the HttpClient inside).
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Mar 17, 2022 at 12:17 PM Jan Høydahl wrote:
> To
a specific "Apache" http client vs whatever other ones.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Mar 18, 2022 at 12:28 AM David Smiley wrote:
> Thank you for accepting my proposal -- I definitely volunteer to implement
>
may have?
One idea I've had is to have the Jenkins job for the builds include a
reproducibility step -- an encore for the failing tests to try to do their
thing again. Then we could differentiate the build status this way --
Unstable vs Failure on the reproducibility.
~ David Smiley
Apach
Congrats Houston and thanks for your PMC chores Jan!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Mar 17, 2022 at 11:36 AM Houston Putman wrote:
> Thanks Jan!
>
> Thank you so much for all of the hard work you have done over
not care much about the other side. Still, for HttpSolrClient in
particular (the most common), it's not too late to un-deprecate it, and a
similar change could happen later. Interestingly, BaseHttpSolrClient has
nothing of interest, unlike the cloud side of things.
~ David Smiley
Apac
I have too little time to do more so the current state is it for me.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Mar 23, 2022 at 9:05 AM Jan Høydahl wrote:
> If you feel inclined for a cleanup go ahead.
> But I think we can just a
Woohoo!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Mar 25, 2022 at 4:16 PM Jan Høydahl wrote:
> Hi,
>
> All code blockers are now cleared:
> https://issues.apache.org/jira/issues/?filter=12351219
> Some work remains f
owse/SOLR-16145
Also, I want to point out a minor issue: the distribution doesn't include
the docker "examples" subdirectory, and maybe some others misc
files/directories specific to some modules:
https://github.com/apache/lucene-solr/pull/2104 (I guess I need to redo
this)
~
he.org/confluence/display/SOLR/2022-04+Meeting+notes
The meeting can be a good sounding board for socializing new things you are
working on or for discussing pain points. And of course just to say
"hello" :-)
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/dav
Thanks for stepping up Houston! I'll create the calendar invite. There's
a 25% chance I'll miss it at this date & time, so... perhaps you'd accept
one hour earlier? Europe would like this more :-)
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.
This definitely needs to be addressed; basic working Maven coordinates are
important. Next time I guess we need to validate this via the smoke
tester, I suppose?
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Apr 13, 2022 at 5:59 PM Anshum
(no opinion) but thanks for driving this.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Apr 15, 2022 at 12:23 PM Kevin Risden wrote:
> +1 option 2
>
> Kevin Risden
>
>
> On Fri, Apr 15, 2022 at 12:04 PM Ishan Chattopadhyay
I'm glad you raise the question here but definitely raise this on the
SOLR-14663 as well so that you get attention from pertinent folks there. I
wouldn't be surprised if some of our users have JIRA accounts but don't
subscribe to this list.
~ David Smiley
Apache Lucene/Solr Search
On Tue, Apr 26, 2022 at 12:50 PM Gus Heck wrote:
> I was shocked to discover https://issues.apache.org/jira/browse/SOLR-14967
> causes solr to violate one of it's most key precepts that zk is not
> involved on every query.
>
> In looking into this, I ran across this code:
>
> https://github.com/a
re were issues. I'm on travel at the moment but if someone has
tips on where to locate them / how to use them (anything non-obvious), I'd
appreciate it.
BTW thanks to everyone (esp. Jan & Houston) doing the legwork of doing the
release. And the manual release checking I see most of
+1 (binding)
SUCCESS! [0:45:47.169811]
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, May 9, 2022 at 8:58 AM Jason Gerlowski
wrote:
> +1 (binding)
>
> SUCCESS! [1:02:41.827601]
>
> Ran the smoketester and did some m
ny notification / email
about this, simply let me know and I will add you. Then henceforth, I
imagine it'll be a non-issue for you.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Sun, May 8, 2022 at 7:51 PM Houston Putman wrote:
> Thanks
As usual, I recorded the session. It was an hour long. If you're a
committer who wants access, just let me know and I will share it!
Woohoo!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, May 10, 2022 at 11:09 AM Jan Høydahl wrote:
> It's been >72h since the vote was initiated and the result is:
>
> +1 11 (9 binding)
> 0 0
> -1 0
>
>
yntax and
Parsers". The same issue is here with the "Indexing Guide". The other
panels don't seem to have this problem.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, May 10, 2022 at 1:39 PM Marcus Eagan wrote:
> +1
t cause unless we were to enforce a
particular configured list of inspections (which is IntelliJ only,
remember).
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, May 27, 2022 at 12:52 PM Shawn Heisey wrote:
> On 5/27/2022 8:24 AM, Eric Pugh wrot
I merged SOLR-16227 to main, 9, 8.11 some minutes ago.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Jun 3, 2022 at 1:59 PM Mike Drob wrote:
> Yes, please fix and backport SOLR-16227, it looks almost ready from the
> conversation on
Welcome Markus!
Thanks for contributing to Solr over the years.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Jun 21, 2022 at 2:13 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:
> Hello everyone.
>
page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17234635
When deeming something is not used/needed, I recommend digging through
commit history & JIRA, and even commenting on the JIRA introducing whatever
it was years later to ask questions like this.
~ David Smiley
Apache Lucene/Sol
On Tue, Jul 5, 2022 at 10:48 AM Houston Putman wrote:
> That, or maybe the distributed update processor checks the state of the
> cluster on a failure and if the replica no longer exists, it acts
> accordingly.
>
That is what we're exploring.
Yeah; agreed with Houston. I think it's working as designed.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Jul 11, 2022 at 11:40 AM Houston Putman wrote:
> From my understanding, that method is supposed to basically escape
>
Makes sense Bram.
I note that it's been over a month with no response. Just a suggestion --
try commenting on the pertinent JIRA because it will get the attention of
the last committer (and interested parties).
BTW we could cap the initial ArrayList size to, say, Math.min(1024,n)
~ David S
d in a POC and immediately
loved that I had a simple UI that I didn't have to write/maintain.
Let's not constrain ourselves with supporting the current v2 API on Solr
10! Doing so increases the risk that this API change won't even happen in
the first place because it's too hard.
On Thu, Jul 14, 2022 at 4:31 PM Jason Gerlowski
wrote:
> > I think it would be best to tackle one limited area first so we can see
> it in practice both at the surface and implementation.
>
> I think that makes sense, assuming that by "tackling" you mean
> updating the API path/verb/etc and movin
The migration you speak of is in Lucene, not Solr. It would be noticed by
"Watchers".
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Jul 19, 2022 at 12:29 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Great
id running them at the CLI during normal development to keep
us productive. Obviously, slow tests need to run _sometimes_, which I
think should be at least CI & probably PR validation too.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Jul
? I wouldn't be surprised
if disabling Slow could make a big difference for Solr due to the long tail
of slower tests and Gradle's inability to keep all workers busy.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Fri, Jul 22, 2022 at 9:58 PM Mi
ded. I
haven't researched the alternatives yet but compatibility is paramount
because Solr 8 is the previous release and we wouldn't want to do anything
disruptive.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
1 - 100 of 782 matches
Mail list logo
