Re: 8.6.3 Release

Simultaneous releases are also confusing for users, in addition to the back-compat tests as our website chronologically lists our releases and it gets complicated for someone reading the 'News' page. As 8.7 isn't a release that needs to be rushed, waiting until 8.6.3 is released and back-compat

Re: restlet dependencies

> Hmmm; seems the configSet API doesn't have an API to update a single file! I wonder if uploading a configSet to the same name effectively overwrites newly updated files but does not delete the existing files? I've been working on this recently. As of 8.7, the UPLOAD command supports overwriting

Re: restlet dependencies

+1 to deprecate managed resources in lieu of easier to maintain (and more flexible) file based GET/PUT into the configset. > I don't know if 9 is too soon from a deprecation stand point IMO it's never too soon as long as there is a deprecated release. Users take their time upgrading to major

Re: Apache Bug Bash

Note that error prone is part of our standard compilation already. On Wed, Sep 23, 2020 at 6:14 PM Alexandre Rafalovitch wrote: > On Wed, 23 Sep 2020 at 18:56, Tom DuBuisson wrote: > > > On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch < > arafa...@gmail.com> wrote: > > >> I would be

Re: Apache Bug Bash

On Wed, 23 Sep 2020 at 18:56, Tom DuBuisson wrote: > On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch > wrote: >> I would be super-curious to see how well it would be able to support >> Solr's gradle build with all the dark magic we seem to have in it. > > > Perhaps I should keep it a

Re: Apache Bug Bash

On Wed, Sep 23, 2020 at 9:11 AM Alexandre Rafalovitch wrote: > I just tested this on my personal tiny Java project and it is > (committer) +1 from me. Did not test it as part of a PR process, > though would be super excited if I could retroactively graft it on my > current one somehow:

Re: 8.6.3 Release

Jason: Thanks for volunteering to do an 8.6.3! I recently fixed SOLR-14768 , multipart HTTP POST was broken in 8.6 (a regression I introduced). If you can't do the release or need help, I will take over. It's the least I can offer in repentance

Re: Apache Bug Bash

Sounds great! I'll try and be more responsive to any bugs reported through the bash. +1 (PMC) ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Sep 23, 2020 at 11:56 AM Tom DuBuisson wrote: > Lucene Developers, > > As part of our sponsorship

Re: 8.6.3 Release

Simultaneous releases are problematic for our backward-compatibility tests, but we do not need to wait between releases, we could start the release process right away when 8.6.3 is out. I don't think there's any potential for confusion. We've done this several times in the past, e.g. 7.1.0 was

Re: 8.6.3 Release

The release process is not conducive to simultaneous releases. We need to space them out. On Thu, Sep 24, 2020 at 12:01 AM Atri Sharma wrote: > I am not sure if two close releases are a good idea — would they not lead > to potential confusion amongst users? > > In any case, I will defer to the

Re: 8.6.3 Release

I am not sure if two close releases are a good idea — would they not lead to potential confusion amongst users? In any case, I will defer to the opinion of committers. On Wed, 23 Sep 2020 at 23:46, Jason Gerlowski wrote: > > do we want to delay that? > > > > It wasn't my intention to delay

Re: 8.6.3 Release

> do we want to delay that? It wasn't my intention to delay 8.7. The releases will end up being close together, but they're on different release lines so there's nothing wrong with that necessarily. Unless there's something inherent to the release process that makes it difficult to have two

Re: Apache Bug Bash

I just tested this on my personal tiny Java project and it is (committer) +1 from me. Did not test it as part of a PR process, though would be super excited if I could retroactively graft it on my current one somehow: https://github.com/apache/lucene-solr/pull/1863 I've also signed up for the

Apache Bug Bash

Lucene Developers, As part of our sponsorship of ApacheCon, our company MuseDev is doing a Bug Bash for select Apache projects. We'll bring members of the ApacheCon community together to find and fix a range of security and performance bugs during the conference, and gameify the experience with

Re: Code Analysis during CI?

Alex, Yes Lucene is part of that. I merely forgot the lucene email after having put this project aside so I could make a custom email given our ongoing conversation. I'll send it now. -Tom On Wed, Sep 23, 2020 at 7:15 AM Alexandre Rafalovitch wrote: > ApacheCon is apparently running

Re: restlet dependencies

Even better! I still favor removing it in 9 but if not, this sounds like a good approach On Wed, Sep 23, 2020 at 8:54 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > We don't need Jersey either. It is already possible for Solr to accept > arbitrarily nested paths for endpoints

Re: bin/solr testing surprise with techproducts example

The wiki has steps to build solr with gradle https://cwiki.apache.org/confluence/display/SOLR/Building+Solr+with+Gradle ./gradlew assemble or ./gradlew dev will create runnable solr instance. On Wed, Sep 23, 2020, 8:01 PM Christine Poerschke (BLOOMBERG/ LONDON) < cpoersc...@bloomberg.net>

Re: 8.6.3 Release

I was planning on a branch cut on 30th September for 8.7 — do we want to delay that? On Wed, 23 Sep 2020 at 19:37, Jason Gerlowski wrote: > Hi all, > > > > I ran into a query-parsing bug recently in SOLR-14859 that caused > > problems for some of my usecases. I wanted to volunteer as RM for an

Re: 8.6.3 Release

+1 On Wed, 23 Sep, 2020, 8:23 pm Andrzej Białecki, wrote: > I’d like to fix & backport SOLR-14850 & SOLR-14835. > > > On 23 Sep 2020, at 16:06, Jason Gerlowski wrote: > > > > Hi all, > > > > I ran into a query-parsing bug recently in SOLR-14859 that caused > > problems for some of my usecases.

Re: restlet dependencies

We don't need Jersey either. It is already possible for Solr to accept arbitrarily nested paths for endpoints (using annotations) without using Restlet or Jersey. On Wed, 23 Sep, 2020, 8:16 pm Alexandre Rafalovitch, wrote: > How much harder are the use-cases currently covered by managed >

Re: 8.6.3 Release

I’d like to fix & backport SOLR-14850 & SOLR-14835. > On 23 Sep 2020, at 16:06, Jason Gerlowski wrote: > > Hi all, > > I ran into a query-parsing bug recently in SOLR-14859 that caused > problems for some of my usecases. I wanted to volunteer as RM for an > 8.6.3 to get a bugfix release out

Re: restlet dependencies

How much harder are the use-cases currently covered by managed resources, if that module was removed? For standalone instances, it is nearly as easy to edit the file and reload the schema. And it will probably be more version-control friendly than the files currently saved by the module. What

bin/solr testing surprise with techproducts example

Hello everyone. So I was trying to locally test the small https://issues.apache.org/jira/browse/SOLR-11167 change on master branch and encountered two things: Question: What is the replacement for "cd solr ; ant dist server" usage? If there is an equivalent -- "./gradlew -p solr assembleDist"

Re: restlet dependencies

I agree we should deprecate the managed resources feature, it was the first thing I was asked to build by LW nearly 7 years ago, before I was a committer. Restlet was already in place and I built on top of that, not sure who introduced it originally (nor do I care). Clearly from the vantage point

Re: Code Analysis during CI?

ApacheCon is apparently running Muse-based CodeBash. Are we part of that? Regards, Alex. On Wed, 9 Sep 2020 at 05:22, Bruno Roustant wrote: > > +1 for analysis within the PR workflow. > > Le ven. 4 sept. 2020 à 06:38, David Smiley a écrit : >> >> Sounds great to me! I'm really glad to hear

8.6.3 Release

Hi all, I ran into a query-parsing bug recently in SOLR-14859 that caused problems for some of my usecases. I wanted to volunteer as RM for an 8.6.3 to get a bugfix release out for users that aren't ready for some of the bigger changes in 8.7 I was thinking of cutting the branch in a week's