Re: 8.6.3 Release

[Anshum Gupta]

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 indexes are pushed will make things easier for the
RMs and community.

On Wed, Sep 23, 2020 at 1:43 PM David Smiley  wrote:

> 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 for the regression.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 23, 2020 at 10:07 AM 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 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 time to give others a
>> chance to backport any bug-fixes they might want included, with an RC
>> to follow shortly.  Does anyone have any concerns with that plan, or
>> have anything they'd like to fix or backport before an 8.6.3 goes out?
>>
>> Best,
>>
>> Jason
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

-- 
Anshum Gupta

Re: restlet dependencies

[Tomás Fernández Löbbe]

> 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 (before, an UPLOAD on an existing configset name would fail
with BAD_REQUEST) and you can choose to cleanup or not the extra files with
the "cleanup" parameter.
You could upload a single file if you say overwrite=true=false, but
it would still need to be in a zip file (and needs to be located in the
right path of the zip, for example, a synonyms file may be in
lang/synonyms_foo.txt or something)

On Wed, Sep 23, 2020 at 8:10 PM David Smiley  wrote:

> +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 versions.
>
> > How much harder are the use-cases currently covered by managed
> resources, if that module was removed?
>
> I believe in practice, users synchronize one-way from their DB to Solr if
> they have dynamic resources like this.  This is true where I work.
> Otherwise, they would probably be using Solr as the source of truth, which
> doesn't seem architecturally-sound for most apps IMO.  Those users
> (hopefully few) would have to spend some time re-engineering the approach.
> Given one-way sync, the transition here is pretty easy:  serialize the
> client-managed data to the right Solr format (stopwords vs synonyms vs ...)
> and then a file upload to Solr/ZK and then telling Solr which collections
> to "reload".
>
> 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?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter 
> wrote:
>
>> 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 of looking back, JAX-RS and Jersey won the day with REST in Java but
>> that simply wasn't the case back then. What's important is how we move
>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>> made many years ago.
>>
>> In the short term, does Apache have an Artifactory (or similar) where we
>> can host the Restlet dependencies for Github to pull them from? If not,
>> then we can port the code that's using Restlet over to using JAX-RS /
>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>> instead of porting the Restlet code but I don't know if 9 is too soon from
>> a deprecation stand point?
>>
>> Tim
>>
>>
>> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul  wrote:
>>
>>> We should deprecate that feature and remove restlet dependency altogether
>>>
>>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein 
>>> wrote:
>>> >
>>> > Restlet again!!!
>>> >
>>> >
>>> >
>>> > Joel Bernstein
>>> > http://joelsolr.blogspot.com/
>>> >
>>> >
>>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>>> ep...@opensourceconnections.com> wrote:
>>> >>
>>> >> Do we have a community blessed alternative to restlet already?
>>> >>
>>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul  wrote:
>>> >>
>>> >> Haha.
>>> >>
>>> >> In fact schema APIs don't use restlet. Only the managed resources use
>>> it
>>> >>
>>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> >>>
>>> >>> If I were talend, I'd immediately start publishing to maven central.
>>> If I were the developer who built the schema APIs, I would never have used
>>> restlet to begin with.
>>> >>>
>>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, 
>>> wrote:
>>> 
>>>  I was thinking the same. Because GitHub does not cache the
>>> downloaded artifacts like our jenkins servers.
>>> 
>>>  It seems to run it in a new VM or container every time, so it
>>> downloads all artifacts. If I were Talend, I'd also block this.
>>> 
>>>  Uwe
>>> 
>>>  Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>>> dawid.we...@gmail.com>:
>>> >
>>> > I don't think it's http/https - I believe restlet repository simply
>>> > bans github servers because of excessive traffic? These URLs work
>>> for
>>> > me locally...
>>> >
>>> > Dawid
>>> >
>>> > On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>> > LONDON)  wrote:
>>> >>
>>> >>
>>> >>  This sounds vaguely familiar. 

Re: restlet dependencies

[David Smiley]

+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 versions.

> How much harder are the use-cases currently covered by managed resources,
if that module was removed?

I believe in practice, users synchronize one-way from their DB to Solr if
they have dynamic resources like this.  This is true where I work.
Otherwise, they would probably be using Solr as the source of truth, which
doesn't seem architecturally-sound for most apps IMO.  Those users
(hopefully few) would have to spend some time re-engineering the approach.
Given one-way sync, the transition here is pretty easy:  serialize the
client-managed data to the right Solr format (stopwords vs synonyms vs ...)
and then a file upload to Solr/ZK and then telling Solr which collections
to "reload".

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?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter 
wrote:

> 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 of looking back, JAX-RS and Jersey won the day with REST in Java but
> that simply wasn't the case back then. What's important is how we move
> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
> made many years ago.
>
> In the short term, does Apache have an Artifactory (or similar) where we
> can host the Restlet dependencies for Github to pull them from? If not,
> then we can port the code that's using Restlet over to using JAX-RS /
> Jersey. Personally I'd prefer we remove Managed Resources support from 9
> instead of porting the Restlet code but I don't know if 9 is too soon from
> a deprecation stand point?
>
> Tim
>
>
> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul  wrote:
>
>> We should deprecate that feature and remove restlet dependency altogether
>>
>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein 
>> wrote:
>> >
>> > Restlet again!!!
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> >
>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>> >>
>> >> Do we have a community blessed alternative to restlet already?
>> >>
>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul  wrote:
>> >>
>> >> Haha.
>> >>
>> >> In fact schema APIs don't use restlet. Only the managed resources use
>> it
>> >>
>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>>
>> >>> If I were talend, I'd immediately start publishing to maven central.
>> If I were the developer who built the schema APIs, I would never have used
>> restlet to begin with.
>> >>>
>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler,  wrote:
>> 
>>  I was thinking the same. Because GitHub does not cache the
>> downloaded artifacts like our jenkins servers.
>> 
>>  It seems to run it in a new VM or container every time, so it
>> downloads all artifacts. If I were Talend, I'd also block this.
>> 
>>  Uwe
>> 
>>  Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>> >
>> > I don't think it's http/https - I believe restlet repository simply
>> > bans github servers because of excessive traffic? These URLs work
>> for
>> > me locally...
>> >
>> > Dawid
>> >
>> > On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> > LONDON)  wrote:
>> >>
>> >>
>> >>  This sounds vaguely familiar. "http works, https does not work"
>> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>> >>
>> >>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> >>  To: dev@lucene.apache.org
>> >>  Subject: Re: restlet dependencies
>> >>
>> >>  I don't think it is, sadly.
>> >>  https://repo1.maven.org/maven2/org/restlet
>> >>
>> >>  The link you provided (mvnrepository) aggregates from several
>> maven
>> >>  repositories.
>> >>
>> >>
>> >>  D.
>> >>
>> >>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >>   wrote:
>> >>>
>> >>>
>> >>>  Sorry, afk, but I heard (*hearsay*) that restlet is also on
>> maven central
>> >>
>> >> these days. Can we confirm and switch to that? Sorry, if that's
>> not the case.
>> >>>
>> >>>
>> >>>  On Fri, 18 Sep, 2020, 1:15 pm Dawid 

Re: Apache Bug Bash

[Mike Drob]

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 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 secret and ratchet up the suspense, but I'm
> not much of a showman.
>
> >
>
> > The Infer and FSB tools ran on Solr seemingly fine (
> https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr=results)
> but with the noise level you expect on a large project with subtle
> invariants.  The error prone results are lacking so I'll investigate.
>
> >
>
> The results are long enough that they could benefit from faceted
>
> search by source, file, error type, etc. I wish there was an
>
> open-source product you could leverage for such custom structured
>
> search :-) (Yes, I realize your primary interface is PR with much less
>
> noise)
>
>
>
> >>
>
> >> P.p.s. Medium term, I would love to write a custom check that
>
> >> complains about missing @since Javadoc tags for anything that is
>
> >> pluggable/module like, including Analyzers, UpdateRequestProcessors,
>
> >> Stream Components, etc. Knowing when each individual module is
>
> >> introduced is super useful for those on older versions and my previous
>
> >> attempts at fixing this required standalone code that even I cannot
>
> >> get to run again easily now.
>
> >
>
> >
>
> > I know we tweeted about this, but to bring that conversation to the ML:
> The fastest way to write such a check is probably with an Error Prone
> plugin.  There isn't any support yet for ErrorProne plugins inside of Muse,
> but this has been on our minds for a while.  If someone beats me ot making
> an error prone pass then I'll gladly make a way to run it.
>
>
>
> I have given error-prone a quick go. It works nicely when I installed
>
> IntelliJ plugin linked from their website.
>
>
>
> But for custom plugin. Let's just say I got lost between
>
> annotation processing during plugin compilation, annotation processing
>
> including plugin, module/project dependencies and IntelliJ Idea's
>
> options to make it work. So, I could not get a trivial example end to
>
> end in Idea's default project setup.
>
>
>
> But they have an example that I could import into IntelliJ idea
>
> and get it to work with Gradle setup:
>
> https://github.com/google/error-prone/tree/master/examples/plugin/gradle
>
> (clone whole repo, point IntelliJ at just that directory as a project,
>
> let it recognize Gradle, etc).
>
>
>
> So, theoretically, if you take that custom plugin and manage to figure
>
> out how to apply it to a custom project, I can keep beating my head on
>
> my own specialized needs in parallel.
>
>
>
> Anyway, the rest of this thread is probably not lucene-dev worthy. At
>
> least not until there is something to show.
>
>
>
> Regards,
>
>Alex.
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>

Re: Apache Bug Bash

[Alexandre Rafalovitch]

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 secret and ratchet up the suspense, but I'm not 
> much of a showman.
>
> The Infer and FSB tools ran on Solr seemingly fine 
> (https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr=results)
>  but with the noise level you expect on a large project with subtle 
> invariants.  The error prone results are lacking so I'll investigate.
>
The results are long enough that they could benefit from faceted
search by source, file, error type, etc. I wish there was an
open-source product you could leverage for such custom structured
search :-) (Yes, I realize your primary interface is PR with much less
noise)

>>
>> P.p.s. Medium term, I would love to write a custom check that
>> complains about missing @since Javadoc tags for anything that is
>> pluggable/module like, including Analyzers, UpdateRequestProcessors,
>> Stream Components, etc. Knowing when each individual module is
>> introduced is super useful for those on older versions and my previous
>> attempts at fixing this required standalone code that even I cannot
>> get to run again easily now.
>
>
> I know we tweeted about this, but to bring that conversation to the ML: The 
> fastest way to write such a check is probably with an Error Prone plugin.  
> There isn't any support yet for ErrorProne plugins inside of Muse, but this 
> has been on our minds for a while.  If someone beats me ot making an error 
> prone pass then I'll gladly make a way to run it.

I have given error-prone a quick go. It works nicely when I installed
IntelliJ plugin linked from their website.

But for custom plugin. Let's just say I got lost between
annotation processing during plugin compilation, annotation processing
including plugin, module/project dependencies and IntelliJ Idea's
options to make it work. So, I could not get a trivial example end to
end in Idea's default project setup.

But they have an example that I could import into IntelliJ idea
and get it to work with Gradle setup:
https://github.com/google/error-prone/tree/master/examples/plugin/gradle
(clone whole repo, point IntelliJ at just that directory as a project,
let it recognize Gradle, etc).

So, theoretically, if you take that custom plugin and manage to figure
out how to apply it to a custom project, I can keep beating my head on
my own specialized needs in parallel.

Anyway, the rest of this thread is probably not lucene-dev worthy. At
least not until there is something to show.

Regards,
   Alex.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Apache Bug Bash

[Tom DuBuisson]

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: https://github.com/apache/lucene-solr/pull/1863


I have a script or two that helps with this sort of test, it's a bit manual
so I ran and am awaiting results:
https://staging.muse.dev/result/TomMD/lucene-solr/01EJYJ8VRS8K52P95RKFBQAE1Y?tab=logs


> Hopefully, I will end up on a Solr team, there was no
> way to indicate that (Tom!).
>

Victoria (CCed) can make this a fact, not a hope!  There are only so many
options we wanted to present to people in the signup.  Anything can be
changed, we'll be here the whole time.


> 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 secret and ratchet up the suspense, but I'm not
much of a showman.

The Infer and FSB tools ran on Solr seemingly fine (
https://console.muse.dev/result/TomMD/lucene-solr/01EG97PRSVXT35Z1E9T3SKA9V2?search=solr=results)
but with the noise level you expect on a large project with subtle
invariants.  The error prone results are lacking so I'll investigate.


> P.p.s. Medium term, I would love to write a custom check that
> complains about missing @since Javadoc tags for anything that is
> pluggable/module like, including Analyzers, UpdateRequestProcessors,
> Stream Components, etc. Knowing when each individual module is
> introduced is super useful for those on older versions and my previous
> attempts at fixing this required standalone code that even I cannot
> get to run again easily now.
>

I know we tweeted about this, but to bring that conversation to the ML: The
fastest way to write such a check is probably with an Error Prone plugin.
There isn't any support yet for ErrorProne plugins inside of Muse, but this
has been on our minds for a while.  If someone beats me ot making an error
prone pass then I'll gladly make a way to run it.


>
> On Wed, 23 Sep 2020 at 11:56, Tom DuBuisson  wrote:
> >
> > 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 teams, a
> leaderboard, and prizes. The bash is open to everyone whether attending the
> conference or not, and our whole dev team will also be participating to
> help fix as many bugs as we can.
> >
> > We're seeding the bug list with results from Muse, our code analysis
> platform, which runs as a Github App and comments on possible bugs as part
> of the pull request workflow.  Here's an example of what it looks like:
> >
> > https://github.com/curl/curl/pull/5971#discussion_r490252196
> >
> > We explored a number of Apache projects and are reaching out because our
> analysis through Muse found some interesting bugs that could be fixed
> during the Bash.  If this sounds familiar it's because I've been talking a
> bit on this mailing list about Muse already. There has already been a bug
> fix based on the tool findings, a prior conversation "Code Analysis during
> CI?", and a PR adding configuration information for the GitHub App.
> >
> > We're writing to see if you'd be interested in having your project
> included in the Bash. Everything is set up on our end, and while we're
> already working with the infrastructure team to get lucene-solr added (with
> the PR and other conversation as evidence of support) it would help if you
> say yes on this listserv as a clear signal to the Apache Infrastructure
> team to grant Muse access to your Github mirror.
> >
> > We'll then make sure it's all set-up and ready for the Bash. And of
> course, everyone on the project is most welcome to join the Bash and help
> us smash some bugs.
> >
> > -Tom
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 8.6.3 Release

[David Smiley]

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 for
the regression.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Sep 23, 2020 at 10:07 AM 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 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 time to give others a
> chance to backport any bug-fixes they might want included, with an RC
> to follow shortly.  Does anyone have any concerns with that plan, or
> have anything they'd like to fix or backport before an 8.6.3 goes out?
>
> Best,
>
> Jason
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Apache Bug Bash

[David Smiley]

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 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 teams, a
> leaderboard, and prizes. The bash is open to everyone whether attending the
> conference or not, and our whole dev team will also be participating to
> help fix as many bugs as we can.
>
> We're seeding the bug list with results from Muse, our code analysis
> platform, which runs as a Github App and comments on possible bugs as part
> of the pull request workflow.  Here's an example of what it looks like:
>
> https://github.com/curl/curl/pull/5971#discussion_r490252196
>
> We explored a number of Apache projects and are reaching out because our
> analysis through Muse found some interesting bugs that could be fixed
> during the Bash.  If this sounds familiar it's because I've been talking a
> bit on this mailing list about Muse already. There has already been a bug
> fix based on the tool findings, a prior conversation "Code Analysis during
> CI?", and a PR adding configuration information for the GitHub App.
>
> We're writing to see if you'd be interested in having your project
> included in the Bash. Everything is set up on our end, and while we're
> already working with the infrastructure team to get lucene-solr added (with
> the PR and other conversation as evidence of support) it would help if you
> say yes on this listserv as a clear signal to the Apache Infrastructure
> team to grant Muse access to your Github mirror.
>
> We'll then make sure it's all set-up and ready for the Bash. And of
> course, everyone on the project is most welcome to join the Bash and help
> us smash some bugs.
>
> -Tom
>

Re: 8.6.3 Release

[Adrien Grand]

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
released right after 7.0.1 and 8.4.0 was released right after 8.3.1.

Jason, you mentioned cutting a branch but we only do this for minor
releases. Patch versions get released from the minor branch, branch_8_6 in
this case, so we don't need to cut a branch and can proceed directly with
building a release candidate.

As branch_8_6 should be pretty stable by now I wonder if we really need to
wait one week? If we built a RC on Friday instead for instance and the
first vote is successful, we might not even need to delay our current plans
for 8.7.

On Wed, Sep 23, 2020 at 9:18 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> 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 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 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
>>>
>>> in-flight simultaneously? (I haven't RM'd a release yet, so there may
>>>
>>> well be.  Though now that I think back I'm pretty sure other
>>>
>>> committers have done this sort of thing before...)
>>>
>>>
>>>
>>> Was there a particular reason you brought up delaying 8.7?
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Sep 23, 2020 at 11:11 AM Atri Sharma  wrote:
>>>
>>> >
>>>
>>> > 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
>>>
>>> >>
>>>
>>> >> 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 time to give others a
>>>
>>> >>
>>>
>>> >> chance to backport any bug-fixes they might want included, with an RC
>>>
>>> >>
>>>
>>> >> to follow shortly.  Does anyone have any concerns with that plan, or
>>>
>>> >>
>>>
>>> >> have anything they'd like to fix or backport before an 8.6.3 goes out?
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> Best,
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> Jason
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> -
>>>
>>> >>
>>>
>>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>
>>> >>
>>>
>>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> > --
>>>
>>> > Regards,
>>>
>>> >
>>>
>>> > Atri
>>>
>>> > Apache Concerted
>>>
>>>
>>>
>>> -
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>>
>>> --
>> Regards,
>>
>> Atri
>> Apache Concerted
>>
>

-- 
Adrien

Re: 8.6.3 Release

[Ishan Chattopadhyaya]

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 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 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
>>
>> in-flight simultaneously? (I haven't RM'd a release yet, so there may
>>
>> well be.  Though now that I think back I'm pretty sure other
>>
>> committers have done this sort of thing before...)
>>
>>
>>
>> Was there a particular reason you brought up delaying 8.7?
>>
>>
>>
>> Jason
>>
>>
>>
>>
>>
>> On Wed, Sep 23, 2020 at 11:11 AM Atri Sharma  wrote:
>>
>> >
>>
>> > 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
>>
>> >>
>>
>> >> 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 time to give others a
>>
>> >>
>>
>> >> chance to backport any bug-fixes they might want included, with an RC
>>
>> >>
>>
>> >> to follow shortly.  Does anyone have any concerns with that plan, or
>>
>> >>
>>
>> >> have anything they'd like to fix or backport before an 8.6.3 goes out?
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Best,
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Jason
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> -
>>
>> >>
>>
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>> >>
>>
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> > --
>>
>> > Regards,
>>
>> >
>>
>> > Atri
>>
>> > Apache Concerted
>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>> --
> Regards,
>
> Atri
> Apache Concerted
>

Re: 8.6.3 Release

[Atri Sharma]

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 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
>
> in-flight simultaneously? (I haven't RM'd a release yet, so there may
>
> well be.  Though now that I think back I'm pretty sure other
>
> committers have done this sort of thing before...)
>
>
>
> Was there a particular reason you brought up delaying 8.7?
>
>
>
> Jason
>
>
>
>
>
> On Wed, Sep 23, 2020 at 11:11 AM Atri Sharma  wrote:
>
> >
>
> > 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
>
> >>
>
> >> 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 time to give others a
>
> >>
>
> >> chance to backport any bug-fixes they might want included, with an RC
>
> >>
>
> >> to follow shortly.  Does anyone have any concerns with that plan, or
>
> >>
>
> >> have anything they'd like to fix or backport before an 8.6.3 goes out?
>
> >>
>
> >>
>
> >>
>
> >> Best,
>
> >>
>
> >>
>
> >>
>
> >> Jason
>
> >>
>
> >>
>
> >>
>
> >> -
>
> >>
>
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> >>
>
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> >>
>
> >>
>
> >>
>
> > --
>
> > Regards,
>
> >
>
> > Atri
>
> > Apache Concerted
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: 8.6.3 Release

[Jason Gerlowski]

> 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
in-flight simultaneously? (I haven't RM'd a release yet, so there may
well be.  Though now that I think back I'm pretty sure other
committers have done this sort of thing before...)

Was there a particular reason you brought up delaying 8.7?

Jason


On Wed, Sep 23, 2020 at 11:11 AM Atri Sharma  wrote:
>
> 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
>>
>> 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 time to give others a
>>
>> chance to backport any bug-fixes they might want included, with an RC
>>
>> to follow shortly.  Does anyone have any concerns with that plan, or
>>
>> have anything they'd like to fix or backport before an 8.6.3 goes out?
>>
>>
>>
>> Best,
>>
>>
>>
>> Jason
>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
> --
> Regards,
>
> Atri
> Apache Concerted

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Apache Bug Bash

[Alexandre Rafalovitch]

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 ApacheCon code bash and confirmed as
mentor availability. How much time I will actually have is a question,
but I will try. Hopefully, I will end up on a Solr team, there was no
way to indicate that (Tom!).

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.

Regards,
   Alex.
P.s. I suspect the full analysis of the code base would still be
rather noisy, but since that's not a default flow of
MuseDev, that should be fine.
P.p.s. Medium term, I would love to write a custom check that
complains about missing @since Javadoc tags for anything that is
pluggable/module like, including Analyzers, UpdateRequestProcessors,
Stream Components, etc. Knowing when each individual module is
introduced is super useful for those on older versions and my previous
attempts at fixing this required standalone code that even I cannot
get to run again easily now.

On Wed, 23 Sep 2020 at 11:56, Tom DuBuisson  wrote:
>
> 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 teams, a leaderboard, 
> and prizes. The bash is open to everyone whether attending the conference or 
> not, and our whole dev team will also be participating to help fix as many 
> bugs as we can.
>
> We're seeding the bug list with results from Muse, our code analysis 
> platform, which runs as a Github App and comments on possible bugs as part of 
> the pull request workflow.  Here's an example of what it looks like:
>
> https://github.com/curl/curl/pull/5971#discussion_r490252196
>
> We explored a number of Apache projects and are reaching out because our 
> analysis through Muse found some interesting bugs that could be fixed during 
> the Bash.  If this sounds familiar it's because I've been talking a bit on 
> this mailing list about Muse already. There has already been a bug fix based 
> on the tool findings, a prior conversation "Code Analysis during CI?", and a 
> PR adding configuration information for the GitHub App.
>
> We're writing to see if you'd be interested in having your project included 
> in the Bash. Everything is set up on our end, and while we're already working 
> with the infrastructure team to get lucene-solr added (with the PR and other 
> conversation as evidence of support) it would help if you say yes on this 
> listserv as a clear signal to the Apache Infrastructure team to grant Muse 
> access to your Github mirror.
>
> We'll then make sure it's all set-up and ready for the Bash. And of course, 
> everyone on the project is most welcome to join the Bash and help us smash 
> some bugs.
>
> -Tom

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Apache Bug Bash

[Tom DuBuisson]

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 teams, a
leaderboard, and prizes. The bash is open to everyone whether attending the
conference or not, and our whole dev team will also be participating to
help fix as many bugs as we can.

We're seeding the bug list with results from Muse, our code analysis
platform, which runs as a Github App and comments on possible bugs as part
of the pull request workflow.  Here's an example of what it looks like:

https://github.com/curl/curl/pull/5971#discussion_r490252196

We explored a number of Apache projects and are reaching out because our
analysis through Muse found some interesting bugs that could be fixed
during the Bash.  If this sounds familiar it's because I've been talking a
bit on this mailing list about Muse already. There has already been a bug
fix based on the tool findings, a prior conversation "Code Analysis during
CI?", and a PR adding configuration information for the GitHub App.

We're writing to see if you'd be interested in having your project included
in the Bash. Everything is set up on our end, and while we're already
working with the infrastructure team to get lucene-solr added (with the PR
and other conversation as evidence of support) it would help if you say yes
on this listserv as a clear signal to the Apache Infrastructure team to
grant Muse access to your Github mirror.

We'll then make sure it's all set-up and ready for the Bash. And of course,
everyone on the project is most welcome to join the Bash and help us smash
some bugs.

-Tom

Re: Code Analysis during CI?

[Tom DuBuisson]

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 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 it works with the PR
> workflow, and only on the files touched in the PR.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >>
> >> On Thu, Sep 3, 2020 at 8:03 PM Tom DuBuisson  wrote:
> >>>
> >>> Tomás,
> >>> Oof, thanks for the note on TOS.  I fixed the link.  The tool can be
> configured and I'm happy to make things work better for your use case.
> Muse is free for public repos and will remain free for open source
> indefinitely.  You can try it and remove it any time - github is in charge
> of access control and provides you as the repository owner with control via
> the website.
> >>>
> >>> On Thu, Sep 3, 2020 at 4:37 PM Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
> 
>  Thanks Tom. I think this could be very useful as long as it can be
> configurable. (The "terms of use here[1] link to "google.com", so I
> couldn't check that, but they claim it's free for public repos, so...). We
> could always try it and remove it if we don't like it? What do others think?
> 
> 
>  [1] https://github.com/apps/muse-dev
> 
>  On Thu, Sep 3, 2020 at 3:06 PM Tom DuBuisson  wrote:
> >
> > Hello Lucene/Solr folks,
> >
> > During Lucene development CI is used for build and unit tests to
> gate merges.  The CI doesn't yet include any analysis tools though, but
> their use has been discussed [1].  I fixed some issues flagged by
> Facebook's Infer and was prompted to bring up the topic here [2].
> >
> > The recent PR fixed some low-hanging fruit that was reported when I
> ran Muse [3] - a github app that is a platform for static analysis tools.
>  Muse's platform bundles the most useful analysis tools, all open source
> with many of them developed by FANG, and triggers analysis on PRs then
> delivers results as comments.
> >
> > Because of the PR-centric workflow you only see issues related to
> the changes in the pull request.  This means that even a project where
> tools give a daunting list of issues can still have quiet day-to-day
> operation. Muse also has options to configure individual tools and turn
> tools or warnings off entirely.  If there are concerns in addition to noise
> and added mental tax on development then I'd really like to hear those
> thoughts.
> >
> > Would you be up for running Muse on the lucene-solr repo?  Let me
> know, and I hope to hear your thoughts on analysis tools either way.
> >
> > -Tom
> >
> > [1]
> https://issues.apache.org/jira/projects/LUCENE/issues/LUCENE-8847
> > [2] https://issues.apache.org/jira/projects/SOLR/issues/SOLR-14819
> > [3] Muse result on Lucene:
> https://console.muse.dev/result/TomMD/lucene-solr/01EH5WXS6C1RH1NFYHP6ATXTZ9?tab=results
> > Muse app link: https://github.com/apps/muse-dev
> > [4] https://github.com/TomMD/lucene-solr/pulls
> > [5] Example of muse commenting on an issue
> https://github.com/TomMD/shiro/pull/2
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: restlet dependencies

[Timothy Potter]

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 (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
>> 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 about for SolrCloud?
>>
>> My feeling is that this module did not catch on, I don't think anybody
>> ever implemented additional managed resources, though I remember
>> seeing Jiras. So, unless there are super-special use cases, I am +1 on
>> deprecating it ASAP for 8.7 and removing it in 9. It will fit with the
>> overall theme of getting slimmer and more consistent.
>>
>> Regards,
>>Alex.
>> P.s. Also, I think the question on SolrUsers about this had limited
>> response and mentioned a security issue.
>>
>>
>> On Wed, 23 Sep 2020 at 10:28, Timothy Potter 
>> wrote:
>> >
>> > 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 of looking back, JAX-RS and Jersey won the day with REST in Java but
>> that simply wasn't the case back then. What's important is how we move
>> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
>> made many years ago.
>> >
>> > In the short term, does Apache have an Artifactory (or similar) where
>> we can host the Restlet dependencies for Github to pull them from? If not,
>> then we can port the code that's using Restlet over to using JAX-RS /
>> Jersey. Personally I'd prefer we remove Managed Resources support from 9
>> instead of porting the Restlet code but I don't know if 9 is too soon from
>> a deprecation stand point?
>> >
>> > Tim
>> >
>> >
>> > On Mon, Sep 21, 2020 at 11:33 PM Noble Paul 
>> wrote:
>> >>
>> >> We should deprecate that feature and remove restlet dependency
>> altogether
>> >>
>> >> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein 
>> wrote:
>> >> >
>> >> > Restlet again!!!
>> >> >
>> >> >
>> >> >
>> >> > Joel Bernstein
>> >> > http://joelsolr.blogspot.com/
>> >> >
>> >> >
>> >> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>> >> >>
>> >> >> Do we have a community blessed alternative to restlet already?
>> >> >>
>> >> >> On Sep 20, 2020, at 9:40 AM, Noble Paul 
>> wrote:
>> >> >>
>> >> >> Haha.
>> >> >>
>> >> >> In fact schema APIs don't use restlet. Only the managed resources
>> use it
>> >> >>
>> >> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >> >>>
>> >> >>> If I were talend, I'd immediately start publishing to maven
>> central. If I were the developer who built the schema APIs, I would never
>> have used restlet to begin with.
>> >> >>>
>> >> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, 
>> wrote:
>> >> 
>> >>  I was thinking the same. Because GitHub does not cache the
>> downloaded artifacts like our jenkins servers.
>> >> 
>> >>  It seems to run it in a new VM or container every time, so it
>> downloads all artifacts. If I were Talend, I'd also block this.
>> >> 
>> >>  Uwe
>> >> 
>> >>  Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>> >> >
>> >> > I don't think it's http/https - I believe restlet repository
>> simply
>> >> > bans github servers because of excessive traffic? These URLs
>> work for
>> >> > me locally...
>> >> >
>> >> > Dawid
>> >> >
>> >> > On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> >> > LONDON)  wrote:
>> >> >>
>> >> >>
>> >> >>  This sounds vaguely familiar. "http works, https does not
>> work" and https://issues.apache.org/jira/browse/SOLR-13756 possibly
>> related?
>> >> >>
>> >> >>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> >> >>  To: dev@lucene.apache.org
>> >> >>  Subject: Re: restlet dependencies
>> >> >>
>> >> >>  I don't think it is, sadly.
>> >> >>  https://repo1.maven.org/maven2/org/restlet
>> >> >>
>> >> >>  The link you provided (mvnrepository) aggregates from several
>> maven
>> >> >>  repositories.
>> >> >>
>> >> >>
>> >> >>  D.
>> >> >>
>> >> >>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >> >>   wrote:
>> >> >>>
>> >> >>>
>> >> >>>  Sorry, afk, but I heard (*hearsay*) that 

Re: bin/solr testing surprise with techproducts example

[Munendra S N]

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> wrote:

> 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" perhaps? --
> then I'd be happy to update
> https://github.com/apache/lucene-solr/blob/master/help/ant.txt with the
> info.
>
> Observation: "cd solr ; bin/solr start -e techproducts" on master branch
> (but not branch_8x) gives me an error. Is this a known issue already or if
> not could someone try to reproduce the issue before a JIRA ticket is opened?
>
> ERROR: Error CREATEing SolrCore 'techproducts': Unable to create core
> [techproducts] Caused by: [schema.xml] analyzer/tokenizer: missing
> mandatory attribute 'class'
>
> Thanks,
>
> Christine
>

Re: 8.6.3 Release

[Atri Sharma]

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
>
> 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 time to give others a
>
> chance to backport any bug-fixes they might want included, with an RC
>
> to follow shortly.  Does anyone have any concerns with that plan, or
>
> have anything they'd like to fix or backport before an 8.6.3 goes out?
>
>
>
> Best,
>
>
>
> Jason
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: 8.6.3 Release

[Ishan Chattopadhyaya]

+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.  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 time to give others a
> > chance to backport any bug-fixes they might want included, with an RC
> > to follow shortly.  Does anyone have any concerns with that plan, or
> > have anything they'd like to fix or backport before an 8.6.3 goes out?
> >
> > Best,
> >
> > Jason
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: restlet dependencies

[Ishan Chattopadhyaya]

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
> 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 about for SolrCloud?
>
> My feeling is that this module did not catch on, I don't think anybody
> ever implemented additional managed resources, though I remember
> seeing Jiras. So, unless there are super-special use cases, I am +1 on
> deprecating it ASAP for 8.7 and removing it in 9. It will fit with the
> overall theme of getting slimmer and more consistent.
>
> Regards,
>Alex.
> P.s. Also, I think the question on SolrUsers about this had limited
> response and mentioned a security issue.
>
>
> On Wed, 23 Sep 2020 at 10:28, Timothy Potter  wrote:
> >
> > 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 of looking back, JAX-RS and Jersey won the day with REST in Java but
> that simply wasn't the case back then. What's important is how we move
> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
> made many years ago.
> >
> > In the short term, does Apache have an Artifactory (or similar) where we
> can host the Restlet dependencies for Github to pull them from? If not,
> then we can port the code that's using Restlet over to using JAX-RS /
> Jersey. Personally I'd prefer we remove Managed Resources support from 9
> instead of porting the Restlet code but I don't know if 9 is too soon from
> a deprecation stand point?
> >
> > Tim
> >
> >
> > On Mon, Sep 21, 2020 at 11:33 PM Noble Paul 
> wrote:
> >>
> >> We should deprecate that feature and remove restlet dependency
> altogether
> >>
> >> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein 
> wrote:
> >> >
> >> > Restlet again!!!
> >> >
> >> >
> >> >
> >> > Joel Bernstein
> >> > http://joelsolr.blogspot.com/
> >> >
> >> >
> >> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >> >>
> >> >> Do we have a community blessed alternative to restlet already?
> >> >>
> >> >> On Sep 20, 2020, at 9:40 AM, Noble Paul 
> wrote:
> >> >>
> >> >> Haha.
> >> >>
> >> >> In fact schema APIs don't use restlet. Only the managed resources
> use it
> >> >>
> >> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >> >>>
> >> >>> If I were talend, I'd immediately start publishing to maven
> central. If I were the developer who built the schema APIs, I would never
> have used restlet to begin with.
> >> >>>
> >> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, 
> wrote:
> >> 
> >>  I was thinking the same. Because GitHub does not cache the
> downloaded artifacts like our jenkins servers.
> >> 
> >>  It seems to run it in a new VM or container every time, so it
> downloads all artifacts. If I were Talend, I'd also block this.
> >> 
> >>  Uwe
> >> 
> >>  Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
> >> >
> >> > I don't think it's http/https - I believe restlet repository
> simply
> >> > bans github servers because of excessive traffic? These URLs work
> for
> >> > me locally...
> >> >
> >> > Dawid
> >> >
> >> > On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
> >> > LONDON)  wrote:
> >> >>
> >> >>
> >> >>  This sounds vaguely familiar. "http works, https does not work"
> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
> >> >>
> >> >>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
> >> >>  To: dev@lucene.apache.org
> >> >>  Subject: Re: restlet dependencies
> >> >>
> >> >>  I don't think it is, sadly.
> >> >>  https://repo1.maven.org/maven2/org/restlet
> >> >>
> >> >>  The link you provided (mvnrepository) aggregates from several
> maven
> >> >>  repositories.
> >> >>
> >> >>
> >> >>  D.
> >> >>
> >> >>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> >> >>   wrote:
> >> >>>
> >> >>>
> >> >>>  Sorry, afk, but I heard (*hearsay*) that restlet is also on
> maven central
> >> >>
> >> >> these days. Can we confirm and switch to that? Sorry, if that's
> not the case.
> >> >>>
> >> >>>
> >> >>>  On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
> dawid.we...@gmail.com> wrote:
> >> 
> >> 
> >>   Just FYI: can't get PR 

Re: 8.6.3 Release

[Andrzej Białecki]

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 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 time to give others a
> chance to backport any bug-fixes they might want included, with an RC
> to follow shortly.  Does anyone have any concerns with that plan, or
> have anything they'd like to fix or backport before an 8.6.3 goes out?
> 
> Best,
> 
> Jason
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: restlet dependencies

[Alexandre Rafalovitch]

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 about for SolrCloud?

My feeling is that this module did not catch on, I don't think anybody
ever implemented additional managed resources, though I remember
seeing Jiras. So, unless there are super-special use cases, I am +1 on
deprecating it ASAP for 8.7 and removing it in 9. It will fit with the
overall theme of getting slimmer and more consistent.

Regards,
   Alex.
P.s. Also, I think the question on SolrUsers about this had limited
response and mentioned a security issue.


On Wed, 23 Sep 2020 at 10:28, Timothy Potter  wrote:
>
> 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 
> of looking back, JAX-RS and Jersey won the day with REST in Java but that 
> simply wasn't the case back then. What's important is how we move forward vs. 
> bestowing judgement backed by wisdom of hindsight on decisions made many 
> years ago.
>
> In the short term, does Apache have an Artifactory (or similar) where we can 
> host the Restlet dependencies for Github to pull them from? If not, then we 
> can port the code that's using Restlet over to using JAX-RS / Jersey. 
> Personally I'd prefer we remove Managed Resources support from 9 instead of 
> porting the Restlet code but I don't know if 9 is too soon from a deprecation 
> stand point?
>
> Tim
>
>
> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul  wrote:
>>
>> We should deprecate that feature and remove restlet dependency altogether
>>
>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein  wrote:
>> >
>> > Restlet again!!!
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> >
>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh 
>> >  wrote:
>> >>
>> >> Do we have a community blessed alternative to restlet already?
>> >>
>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul  wrote:
>> >>
>> >> Haha.
>> >>
>> >> In fact schema APIs don't use restlet. Only the managed resources use it
>> >>
>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya 
>> >>  wrote:
>> >>>
>> >>> If I were talend, I'd immediately start publishing to maven central. If 
>> >>> I were the developer who built the schema APIs, I would never have used 
>> >>> restlet to begin with.
>> >>>
>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler,  wrote:
>> 
>>  I was thinking the same. Because GitHub does not cache the downloaded 
>>  artifacts like our jenkins servers.
>> 
>>  It seems to run it in a new VM or container every time, so it downloads 
>>  all artifacts. If I were Talend, I'd also block this.
>> 
>>  Uwe
>> 
>>  Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss 
>>  :
>> >
>> > I don't think it's http/https - I believe restlet repository simply
>> > bans github servers because of excessive traffic? These URLs work for
>> > me locally...
>> >
>> > Dawid
>> >
>> > On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> > LONDON)  wrote:
>> >>
>> >>
>> >>  This sounds vaguely familiar. "http works, https does not work" and 
>> >> https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>> >>
>> >>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> >>  To: dev@lucene.apache.org
>> >>  Subject: Re: restlet dependencies
>> >>
>> >>  I don't think it is, sadly.
>> >>  https://repo1.maven.org/maven2/org/restlet
>> >>
>> >>  The link you provided (mvnrepository) aggregates from several maven
>> >>  repositories.
>> >>
>> >>
>> >>  D.
>> >>
>> >>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >>   wrote:
>> >>>
>> >>>
>> >>>  Sorry, afk, but I heard (*hearsay*) that restlet is also on maven 
>> >>> central
>> >>
>> >> these days. Can we confirm and switch to that? Sorry, if that's not 
>> >> the case.
>> >>>
>> >>>
>> >>>  On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss,  
>> >>> wrote:
>> 
>> 
>>   Just FYI: can't get PR builds on github to work recently because 
>>  of this:
>> 
>> > Could not resolve all files for configuration
>> >>
>> >> ':solr:core:compileClasspath'.
>> 
>>   350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>   (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>   351 > Could not get resource
>> 
>> >> 

bin/solr testing surprise with techproducts example

[Christine Poerschke (BLOOMBERG/ LONDON)]

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" perhaps? -- then 
I'd be happy to update 
https://github.com/apache/lucene-solr/blob/master/help/ant.txt with the info.

Observation: "cd solr ; bin/solr start -e techproducts" on master branch (but 
not branch_8x) gives me an error. Is this a known issue already or if not could 
someone try to reproduce the issue before a JIRA ticket is opened?

ERROR: Error CREATEing SolrCore 'techproducts': Unable to create core 
[techproducts] Caused by: [schema.xml] analyzer/tokenizer: missing mandatory 
attribute 'class'

Thanks,

Christine

Re: restlet dependencies

[Timothy Potter]

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 of looking back, JAX-RS and Jersey won the day with REST in Java but
that simply wasn't the case back then. What's important is how we move
forward vs. bestowing judgement backed by wisdom of hindsight on decisions
made many years ago.

In the short term, does Apache have an Artifactory (or similar) where we
can host the Restlet dependencies for Github to pull them from? If not,
then we can port the code that's using Restlet over to using JAX-RS /
Jersey. Personally I'd prefer we remove Managed Resources support from 9
instead of porting the Restlet code but I don't know if 9 is too soon from
a deprecation stand point?

Tim


On Mon, Sep 21, 2020 at 11:33 PM Noble Paul  wrote:

> We should deprecate that feature and remove restlet dependency altogether
>
> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein 
> wrote:
> >
> > Restlet again!!!
> >
> >
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> >
> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >>
> >> Do we have a community blessed alternative to restlet already?
> >>
> >> On Sep 20, 2020, at 9:40 AM, Noble Paul  wrote:
> >>
> >> Haha.
> >>
> >> In fact schema APIs don't use restlet. Only the managed resources use it
> >>
> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>>
> >>> If I were talend, I'd immediately start publishing to maven central.
> If I were the developer who built the schema APIs, I would never have used
> restlet to begin with.
> >>>
> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler,  wrote:
> 
>  I was thinking the same. Because GitHub does not cache the downloaded
> artifacts like our jenkins servers.
> 
>  It seems to run it in a new VM or container every time, so it
> downloads all artifacts. If I were Talend, I'd also block this.
> 
>  Uwe
> 
>  Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
> dawid.we...@gmail.com>:
> >
> > I don't think it's http/https - I believe restlet repository simply
> > bans github servers because of excessive traffic? These URLs work for
> > me locally...
> >
> > Dawid
> >
> > On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
> > LONDON)  wrote:
> >>
> >>
> >>  This sounds vaguely familiar. "http works, https does not work"
> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
> >>
> >>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
> >>  To: dev@lucene.apache.org
> >>  Subject: Re: restlet dependencies
> >>
> >>  I don't think it is, sadly.
> >>  https://repo1.maven.org/maven2/org/restlet
> >>
> >>  The link you provided (mvnrepository) aggregates from several maven
> >>  repositories.
> >>
> >>
> >>  D.
> >>
> >>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
> >>   wrote:
> >>>
> >>>
> >>>  Sorry, afk, but I heard (*hearsay*) that restlet is also on maven
> central
> >>
> >> these days. Can we confirm and switch to that? Sorry, if that's not
> the case.
> >>>
> >>>
> >>>  On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, 
> wrote:
> 
> 
>   Just FYI: can't get PR builds on github to work recently because
> of this:
> 
> > Could not resolve all files for configuration
> >>
> >> ':solr:core:compileClasspath'.
> 
>   350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>   (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>   351 > Could not get resource
> 
> >> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >> tlet.ext.servlet-2.4.3.jar'.
> 
>   352 > Could not GET
> 
> >> '
> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
> >> tlet.ext.servlet-2.4.3.jar'.
> 
>   353 > Connection reset
>   354 > Could not download org.restlet-2.4.3.jar
>   (org.restlet.jee:org.restlet:2.4.3)
>   355 > Could not get resource
> 
> >> '
> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
> >> ar'.
> 
>   356 > Could not GET
> 
> >> '
> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
> >> 2.4.3.jar'.
> 
>   357 > Connection reset
> 
>   D.
>  
>   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>   For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Code Analysis during CI?

[Alexandre Rafalovitch]

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 it works with the PR workflow, 
>> and only on the files touched in the PR.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Thu, Sep 3, 2020 at 8:03 PM Tom DuBuisson  wrote:
>>>
>>> Tomás,
>>> Oof, thanks for the note on TOS.  I fixed the link.  The tool can be 
>>> configured and I'm happy to make things work better for your use case.  
>>> Muse is free for public repos and will remain free for open source 
>>> indefinitely.  You can try it and remove it any time - github is in charge 
>>> of access control and provides you as the repository owner with control via 
>>> the website.
>>>
>>> On Thu, Sep 3, 2020 at 4:37 PM Tomás Fernández Löbbe 
>>>  wrote:

 Thanks Tom. I think this could be very useful as long as it can be 
 configurable. (The "terms of use here[1] link to "google.com", so I 
 couldn't check that, but they claim it's free for public repos, so...). We 
 could always try it and remove it if we don't like it? What do others 
 think?


 [1] https://github.com/apps/muse-dev

 On Thu, Sep 3, 2020 at 3:06 PM Tom DuBuisson  wrote:
>
> Hello Lucene/Solr folks,
>
> During Lucene development CI is used for build and unit tests to gate 
> merges.  The CI doesn't yet include any analysis tools though, but their 
> use has been discussed [1].  I fixed some issues flagged by Facebook's 
> Infer and was prompted to bring up the topic here [2].
>
> The recent PR fixed some low-hanging fruit that was reported when I ran 
> Muse [3] - a github app that is a platform for static analysis tools.   
> Muse's platform bundles the most useful analysis tools, all open source 
> with many of them developed by FANG, and triggers analysis on PRs then 
> delivers results as comments.
>
> Because of the PR-centric workflow you only see issues related to the 
> changes in the pull request.  This means that even a project where tools 
> give a daunting list of issues can still have quiet day-to-day operation. 
> Muse also has options to configure individual tools and turn tools or 
> warnings off entirely.  If there are concerns in addition to noise and 
> added mental tax on development then I'd really like to hear those 
> thoughts.
>
> Would you be up for running Muse on the lucene-solr repo?  Let me know, 
> and I hope to hear your thoughts on analysis tools either way.
>
> -Tom
>
> [1] https://issues.apache.org/jira/projects/LUCENE/issues/LUCENE-8847
> [2] https://issues.apache.org/jira/projects/SOLR/issues/SOLR-14819
> [3] Muse result on Lucene: 
> https://console.muse.dev/result/TomMD/lucene-solr/01EH5WXS6C1RH1NFYHP6ATXTZ9?tab=results
> Muse app link: https://github.com/apps/muse-dev
> [4] https://github.com/TomMD/lucene-solr/pulls
> [5] Example of muse commenting on an issue 
> https://github.com/TomMD/shiro/pull/2
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

8.6.3 Release

[Jason Gerlowski]

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 time to give others a
chance to backport any bug-fixes they might want included, with an RC
to follow shortly.  Does anyone have any concerns with that plan, or
have anything they'd like to fix or backport before an 8.6.3 goes out?

Best,

Jason

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org