I was thinking (and I haven’t flushed it out completely but will throw the
idea) that an alternative approach with this timeline could be to cut 9x
branch around November/December? And then you could merge into master, it
would have the latest changes from master plus the ref branch changes.
Hi,
In normal facet request below can be used to filter the facet terms. I am
not able to do the same using json.facet. Please let me know whether I can
raise a JIRA for this. Checked the code and I think I can work on the
changes to support this.
I'm sharing the initial drop of a proposal to remove the Overseer from
SolrCloud.
https://docs.google.com/document/d/1u4QHsIHuIxlglIW6hekYlXGNOP0HjLGVX5N6inkj6Ok/
This is a structural change that I believe requires a large consensus
to be successful or even started. Feedback is most welcome and
Hello,
I am trying to utilize Block Max WAND optimization. During testing,
BooleanQuery that I passed to IndexSearcher.seach() had multiple clauses
and all of them were of Occur.FILTER type. I noticed that when queries do
not have Occur.MUST clauses, BlockMaxConjunctionScorer is not created for
>I don't think it can be said what committers do and don't do with regards
to running Solr. All of us would answer this differently and at different
points in time.
" I have run it in one large cluster, so it is certified to be bug
free/stable" I don't think it's a reasonable approach. We need
> I think the Solr 4 alpha/beta situation was different -- it was not some
fork a committer was maintaining; it was the master branch of its time, and
it was destined to be the very next release, not some possible future
release.
Agree, 4’s alpha/beta was a very different situation.
> I believe
+1 (binding)
SUCCESS! [1:00:37.423566]
Tried basic indexing and search and ran the smoke tester.
On Sat, Oct 3, 2020 at 6:53 PM Jason Gerlowski
wrote:
> Please vote for release candidate 1 for Lucene/Solr 8.6.3
>
>
> The artifacts can be downloaded from:
>
>
>
Thanks so much for your responses Ishan... I'm getting much more
information in this thread than my attempts to get questions answered on
the JIRA issue months ago. And especially, thank you for volunteering for
the difficult porting efforts!
Tomas said:
> I do agree with the previous
+1 (non-binding)
SUCCESS! [0:59:46.680873]
On Mon, Oct 5, 2020 at 11:04 AM Adrien Grand wrote:
> +1 SUCCESS! [1:36:10.395992]
>
> On Mon, Oct 5, 2020 at 2:15 PM Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> +1 (binding)
>>
>> SUCCESS! [0:44:16.898412]
>>
>>
>> Mike McCandless
To conclude this thread, seems that there's general consensus for a release
around early December timeframe. If there are any outstanding concerns
against the release itself, please chime in.
The naming is something we can discuss separately, as we go along. State of
the branch can be
We have a 12 tests failing 100% of the time over the last 24 hours. I urge
folks to take a look at
http://fucit.org/solr-jenkins-reports/failure-report.html and see if anything
rings some bells.
Short form:
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0
+1 SUCCESS! [1:36:10.395992]
On Mon, Oct 5, 2020 at 2:15 PM Michael McCandless
wrote:
> +1 (binding)
>
> SUCCESS! [0:44:16.898412]
>
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Mon, Oct 5, 2020 at 3:28 AM Atri Sharma wrote:
>
>> +1 (binding)
>>
>> SUCCESS! [1:04.32.39193]
Moreover, with more and more helpful information showing up in the codebase
itself lately (as Dawid pointed to), I think we should remove corresponding
information in the wiki. Less to maintain, more/different places of
information can be more confusing.
~ David Smiley
Apache Lucene/Solr Search
IIUC, reference_impl is the branch where the changes are stable. *_dev is
the branch where active development is going on. Once changes are baked in
there, they are promoted to reference_impl. We want to release from
reference_impl.
On Mon, 5 Oct, 2020, 6:16 pm Erick Erickson,
wrote:
> Uwe:
>
>
Uwe:
I think it’s reference_impl_dev...
> On Oct 4, 2020, at 6:00 PM, Uwe Schindler wrote:
>
> Hi,
> I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins
> (Linux, Windows, MacOS).
>
> I used branch (“reference_impl”). Is this correct, because it’s about a month
> old?
>
+1 (binding)
SUCCESS! [0:44:16.898412]
Mike McCandless
http://blog.mikemccandless.com
On Mon, Oct 5, 2020 at 3:28 AM Atri Sharma wrote:
> +1 (binding)
>
> SUCCESS! [1:04.32.39193]
>
> On Sun, Oct 4, 2020 at 7:24 AM Jason Gerlowski
> wrote:
> >
> > Please vote for release candidate 1 for
On 10/3/2020 1:42 PM, Ishan Chattopadhyaya wrote:
As you might be aware, the reference_impl branch has a lot of
improvements that we want to see in Solr master. However, it is
currently a large deviation from master and hence the stability and
reliability (though improved in certain aspects)
+1 (binding)
SUCCESS! [1:04.32.39193]
On Sun, Oct 4, 2020 at 7:24 AM Jason Gerlowski wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.6.3
>
>
> The artifacts can be downloaded from:
>
>
+1
SUCCESS! [1:40:38.242493]
> On 4 Oct 2020, at 03:53, Jason Gerlowski wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.6.3
>
> The artifacts can be downloaded from:
>
> I'm curious if "gradlew idea" is needed.
It is not needed. You should just import gradle project as-is via
IntelliJ built-in mechanisms.
https://github.com/apache/lucene-solr/blob/master/help/IDEs.txt#L1-L4
D.
-
To
20 matches
Mail list logo
