Uwe: the "/view/Lucene-Solr/" View that my reports were using to restrict
the jobs it checked on your jenkins server (to only lucene/solr jobs)
seems to have been removed...
https://jenkins.thetaphi.de/view/Lucene-Solr/
...as a result, my reports evidently haven't detected any
> Autoscaling is another big item, but I think we have to put it into
> 9x, it’s a critical (and critically broken) functionality
I think autoscaling has many aspects to it. The only piece that I find
critical to Solr (SolrCloud / core) is reasonable (not super smart) replica
placement. Rest of
> With 9x having java 11 and gradle migrations on the dev side, and about
to have
> a significant round of deprecations/removals and migrations to plugin for
things
> such as CDCR, DIH etc (see
https://issues.apache.org/jira/browse/SOLR-13442
> and https://issues.apache.org/jira/browse/SOLR-14022)
No more JIRA fields please; "Fix Version" is adequate. You can edit an
issue after creating it to set the "Fix version" to "master (9.0)"; the
issue doesn't have to be resolved yet. I recently had ASF change JIRA so
that this field is not editable on creation of the issue because our
I’ll throw out the same suggestion I made when we had the same conversation
about 6 months ago - we should make a 9.0 Roadmap wiki page, use it to write
down & agree on goals, then add labels to Jira issues so we can go back to the
wiki page and add queries which automatically query Jira and
There’s value IMO in having the discussion in one place rather than having to
search all of the JIRA tickets...
> On Jul 2, 2020, at 2:30 PM, Gus Heck wrote:
>
> Looking at
>
Looking at
https://issues.apache.org/jira/projects/SOLR?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page=unreleased
maybe
this is as simple as having one more field on our issues... Currently fix
version denotes when something got fixed, perhaps a "target version" field
could
Jira typically has features for designating what's in a release
On Thu, Jul 2, 2020 at 1:55 PM Erick Erickson
wrote:
> 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
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.
That said, yeah, I do think it’s time to start getting a handle on 9.0. Pulling
Ant out of
Fixed, apologies. Didn't want enough and compile with JDK8 to test before
push. Lesson for next time.
On Thu, 2 Jul, 2020, 10:42 pm Andrzej Białecki, wrote:
> This breaks branch_8x for me - Java 8 doesn’t recognise the “since”
> attribute in @Deprecated.
>
> > On 2 Jul 2020, at 13:10,
This breaks branch_8x for me - Java 8 doesn’t recognise the “since” attribute
in @Deprecated.
> On 2 Jul 2020, at 13:10, is...@apache.org wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ishan pushed a commit to branch branch_8x
> in repository
Autoscaling is another big item, but I think we have to put it into 9x, it’s a
critical (and critically broken) functionality. We’re making some progress with
Ilan and Noble so I’m cautiously optimistic.
> On 2 Jul 2020, at 18:58, Gus Heck wrote:
>
> Should we have one?
>
> With 9x having
+1
On Thu, Jul 2, 2020 at 10:28 PM Gus Heck wrote:
>
> Should we have one?
>
> With 9x having java 11 and gradle migrations on the dev side, and about to
> have a significant round of deprecations/removals and migrations to plugin
> for things such as CDCR, DIH etc (see
>
Should we have one?
With 9x having java 11 and gradle migrations on the dev side, and about to
have a significant round of deprecations/removals and migrations to plugin
for things such as CDCR, DIH etc (see
https://issues.apache.org/jira/browse/SOLR-13442 and
See: https://issues.apache.org/jira/browse/SOLR-10742
I propose removing it and all associated code. It’s a bit of a sticky wicket,
that method is marked experimental so we’re covered there, but other methods
that pass through to it aren’t.
Erick
Hi Gautam
Please find my answers inline below
Am 02.07.20 um 16:19 schrieb Gautam K:
Dear Team,
Hope you all are doing well.
Can you please help with the following question? We are using Solr
search in our Organisation and now checking whether Solr provides
search capabilities like Google
Cassandra, I fixed the refguide link, verified that I could build the guide and
pushed to all three branches.
Jan
> 2. jul. 2020 kl. 17:06 skrev Jan Høydahl :
>
> It must be the link I added then. I’ll check.
>
> Jan
>
>> 2. jul. 2020 kl. 16:17 skrev Cassandra Targett >
It must be the link I added then. I’ll check.
Jan
> 2. jul. 2020 kl. 16:17 skrev Cassandra Targett :
>
> Jan, the Ref Guide change you made broke the Ref Guide builds.
> On Jul 2, 2020, 7:56 AM -0500, Jan Høydahl , wrote:
>> I forgot to add the new ‘allowPaths’ feature to upgrade notes. Here is
I think it's better to think of Solr as a piece of infrastructure or
component for you to build these things, rather than a product that has a
lot of capabilities for some specific use case.
So you can find 'lego pieces' to build some of these things, but with Solr
you need to build these things
Dear Team,
Hope you all are doing well.
Can you please help with the following question? We are using Solr search
in our Organisation and now checking whether Solr provides search
capabilities like Google Enterprise search(Google Knowledge Graph Search).
1, Does Solr Search provide Voice Search
Is this email thread the only place we are editing the highlights or is
there a Confluence page? I'd rather fix a typo than tell you to fix your
typo :-)
~ David
On Thu, Jul 2, 2020 at 8:56 AM Jan Høydahl wrote:
> I forgot to add the new ‘allowPaths’ feature to upgrade notes. Here is
> what I
Jan, the Ref Guide change you made broke the Ref Guide builds.
On Jul 2, 2020, 7:56 AM -0500, Jan Høydahl , wrote:
> I forgot to add the new ‘allowPaths’ feature to upgrade notes. Here is what I
> plan to commit soon: https://github.com/apache/lucene-solr/pull/1641
>
> Jan
>
> > 2. jul. 2020 kl.
Thanks for bringing this up Atri! Please submit your talk :)
Here's the good news - We introduced the Search track this year. We've
already received a bunch of talks, and I really encourage people to submit
talks about not only Lucene/Solr but also Elastic Search or any other
related search
I forgot to add the new ‘allowPaths’ feature to upgrade notes. Here is what I
plan to commit soon: https://github.com/apache/lucene-solr/pull/1641
Jan
> 2. jul. 2020 kl. 14:18 skrev Mikhail Khludnev :
>
> Query DSL:
> * {param:ref} and {bool: {excludeTags:""}}
>
> On Thu, Jul 2, 2020 at 1:29
Query DSL:
* {param:ref} and {bool: {excludeTags:""}}
On Thu, Jul 2, 2020 at 1:29 PM Bruno Roustant
wrote:
> Here are the draft release notes.
> I tried to keep them concise, but please tell me if I miss something
> important.
>
> Solr 8.6.0 Release Highlights:
>
>- Health Check:
>
Thanks, Jan
On Wed, Jul 1, 2020 at 5:25 PM Jan Høydahl wrote:
>
> And he does not reply to comments either. I closed all his PRs.
>
> Jan Høydahl
>
> 1. jul. 2020 kl. 13:56 skrev Michael Sokolov :
>
>
> Seems like trolling
>
> On Wed, Jul 1, 2020, 6:51 AM GitBox wrote:
>>
>>
>> atris
Unless others object, lets add the following to Solr:
Search:
* Support for BlockMax WAND
Package manager:
* Support for cluster level (CoreContainer level) plugins
On Thu, Jul 2, 2020 at 3:59 PM Bruno Roustant
wrote:
> Here are the draft release notes.
> I tried to keep them concise, but
Here are the draft release notes.
I tried to keep them concise, but please tell me if I miss something
important.
Solr 8.6.0 Release Highlights:
- Health Check:
HealthCheckHandler can now require that all cores are healthy before
returning OK.
- Zookeeper read API:
A read API at
28 matches
Mail list logo
