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

A1, A2, D binding On Thu, Sep 3, 2020 at 7:22 AM Jason Gerlowski wrote: > > A1, A2, D (binding) > > On Wed, Sep 2, 2020 at 10:47 AM Michael McCandless > wrote: > > > > A2, A1, C5, D (binding) > > > > Thank you to everyone for working so hard to make such cool looking > > possible future Lucene

Re: Solr configuration options

Let's take a step back and take a look at the history of Solr. Long ago there was only standalone Solr with a single core there were 3 files * solr.xml : everything required for CoreContainer went here * solr.config.xml : per core configurations go here * schema.xml: this is not relevant for this

Re: Annoying but harmless exceptions due to filepermissions when running tests

I think the best option is to learn to ignore the harmless error message in test logs…… This was one of those “if there were just a few, we can fix the test to set itself up in a writable directory”. But Hoss is right, it’s pretty common to lots and lots and lots of tests and it’s just a minor

Re: Annoying but harmless exceptions due to filepermissions when running tests

There is a flag to disable package manager. Can that code path avoid creating directory? Or maybe it does already. Then tests that don't test that specifically could have disable flag on. Regards, Alex On Wed., Sep. 2, 2020, 9:41 p.m. Noble Paul, wrote: > The filestore dir is where the pack

Re: Annoying but harmless exceptions due to filepermissions when running tests

The filestore dir is where the packages live. If we move it to another location, existing installations might fail. So, it's a backward incompatible change. What are our options? Is it possible to have these directories precreated in the distro/code to ensure that these warnings don't come. On T

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

A1, A2, D (binding) On Wed, Sep 2, 2020 at 10:47 AM Michael McCandless wrote: > > A2, A1, C5, D (binding) > > Thank you to everyone for working so hard to make such cool looking possible > future Lucene logos! And to Ryan for the challenging job of calling this > VOTE :) > > Mike McCandless >

Re: Analytics Module; maybe should be 3rd party?

+1 to having some sort of vote before a big change like moving a contrib. Also +1 to getting feedback on the user list as well; people there might be able to give details on some of the functionality gaps that Houston alluded to. Personally I haven't done anything with the Analytics Component bey

Re: Remove section for 9.0 solr/CHANGES

There will be a “Major Changes in Solr 9” page in the Ref Guide for 9.0 that can cover the removed features and available replacements in detail, which similar pages have done for 6, 7, and 8 so far. I don’t think a page dedicated to deprecated features makes sense beyond the release when the f

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

I’m using zsh shell with oh-my-zsh and the gradle plugin. It adds an alias "gradle=gradle-or-gradlew» which will automatically select ./gradlew when it exists. https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/gradle I also hav

Re: Annoying but harmless exceptions due to filepermissions when running tests

Oh bother. Somehow I thought I’d looked and only a handful of tests reported this. So I looked again and I _wish_ I was able to blame drugs cause you’re right, there are over a thousand of them. Never mind... > On Sep 1, 2020, at 8:55 PM, Chris Hostetter wrote: > > > : Hmmm, that’s kind of

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

The only difference between running your local /usr/bin/gradle vs gradlew should potentially be the gradle version. The purpose of gradlew is to allow a project to force a particular version of gradle. Maintaining backcompat in build.gradle files for features gradle has changed or removed is diffic

The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

Spinning this off of a side comment Dawid made in a jira... : ... Hoss -- you absolutely should use the provided wrapper script, not : your system's gradle. : {code} : hossman@slate:~/lucene/dev/solr/solr-ref-guide [j11] [master] $ gradle buildSite -PsolrGuideVersion=9.0 : {code} : This is

Re: Remove section for 9.0 solr/CHANGES

I agree. With the amount of things going away, a CHANGES.txt section and ref guide page are likely warranted. The ref guide page should be separate from the Upgrade Notes page in the ref guide, as that should already have a fair amount of information. I imagine this page would explain the overall

Re: Remove section for 9.0 solr/CHANGES

We have a "New Features" section already and yeah I could see "Deprecated Features" and/or "Relocated Features" and/or "Removed Features" sections or sub-sections go alongside that. Christine From: dev@lucene.apache.org At: 08/30/20 22:28:19To: dev@lucene.apache.org Subject: Re: Remove section

Re: Approach towards solving split package issues?

I opened LUCENE-9499 as the umbrella. I set "Fix version" to 9.0 - means once we make a commit on it, this will be a blocker for release 9.0.0. (I don't think the changes should be delivered across two major releases; all changes have to be out at once in a major release.) If there are any objectio

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

A2, A1, C5, D (binding) Thank you to everyone for working so hard to make such cool looking possible future Lucene logos! And to Ryan for the challenging job of calling this VOTE :) Mike McCandless http://blog.mikemccandless.com On Tue, Sep 1, 2020 at 4:21 PM Ryan Ernst wrote: > Dear Lucene

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

A2, A1 (binding) On Wed, Sep 2, 2020 at 9:50 AM Ryan Ernst wrote: > Each variant is counted separately. This is why we are doing rank choice > voting. So if you are ok with either A2 or A1, specify both in your vote. > See the rules section in my original email. > > On Tue, Sep 1, 2020, 23:00 S

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

Each variant is counted separately. This is why we are doing rank choice voting. So if you are ok with either A2 or A1, specify both in your vote. See the rules section in my original email. On Tue, Sep 1, 2020, 23:00 Shawn Heisey wrote: > On 9/1/2020 2:21 PM, Ryan Ernst wrote: > > In February

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

A1, A2 (binding) On Wed, Sep 2, 2020 at 8:00 AM Shawn Heisey wrote: > On 9/1/2020 2:21 PM, Ryan Ernst wrote: > > In February a contest was started to design a new logo for Lucene > > [jira-issue]. The initial attempt [first-vote] to call a vote resulted > > in some confusion on the rules, as wel

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

D (binding) I’m not sold on the new proposals. If there’s a problem with vector representation of the old logo, we could pay a designer to do a manual «touch up»? Jan > 1. sep. 2020 kl. 22:21 skrev Ryan Ernst : > > Dear Lucene and Solr developers! > > Sorry for the multiple threads. This sho

Re: [JENKINS] Lucene » Lucene-Solr-NightlyTests-master - Build # 23 - Still unstable!

I'm looking into it. On Wed, Sep 2, 2020 at 7:54 AM Apache Jenkins Server < jenk...@builds.apache.org> wrote: > Build: > https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-NightlyTests-master/23/ > > 3 tests failed. > FAILED: > org.apache.lucene.codecs.lucene87.TestLucene87StoredFieldsFormat