Re: [VOTE] Release Lucene/Solr 8.10.0 RC1

[Cassandra Targett]

OK, they’re fixed in SVN but will take a few minutes to get propagate out to 
the site. I’ll check in a little bit after dinner.
On Sep 22, 2021, 4:34 PM -0500, Cassandra Targett , 
wrote:
> Because when I tried to fix my initial mistake I only updated the HTML pages 
> and thought I could skip updating the image dir but forgot there are new ones 
> :-|
>
> I’ll fix it now.
> On Sep 22, 2021, 3:45 PM -0500, Timothy Potter , wrote:
> > Thank you Cassandra! Any idea why the schema designer images are
> > showing as broken links?
> > https://solr.apache.org/guide/8_10/schema-designer.html ... the images
> > are in images/schema-designer
> >
> > On Wed, Sep 22, 2021 at 2:31 PM Cassandra Targett  
> > wrote:
> > >
> > > I uploaded the 8.10 Ref Guide to https://solr.apache.org/guide/8_10/ in 
> > > DRAFT while we’re voting on the release.
> > >
> > > I accidentally first uploaded a version of the Ref Guide built on `main` 
> > > branch back in March (a leftover from before the project split that 
> > > didn’t get caught with `ant clean`). I’m confident I cleaned it up but 
> > > please let me know if you see something that shouldn’t be there.
> > > On Sep 22, 2021, 1:24 PM -0500, Jan Høydahl , 
> > > wrote:
> > >
> > > +1
> > >
> > > SUCCESS! [1:09:04.477915]
> > >
> > > Just ran smoke tester.
> > >
> > > Jan
> > >
> > > 22. sep. 2021 kl. 17:41 skrev Timothy Potter :
> > >
> > > Please vote for release candidate 1 for Lucene/Solr 8.10.0
> > >
> > > The artifacts can be downloaded from:
> > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> > >
> > > You can run the smoke tester directly with this command:
> > >
> > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> > >
> > > The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00 
> > > UTC.
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove (and reason why)
> > >
> > > Here is my +1 (binding) SUCCESS! [0:56:24.357153]
> > >
> > >
> > > Lastly, for those interested in kicking the tires on Solr using
> > > Docker, I posted an *unofficial* Docker image built locally from the
> > > RC to: thelabdude/apache-solr-dev:8.10.0-rc1
> > >
> > > We just released v0.4.0 of the Apache Solr Operator, so if you want to
> > > try out this RC on Kubernetes, you can use the following YAML config
> > > in your SolrCloud CR definition:
> > >
> > > solrImage:
> > > repository: thelabdude/apache-solr-dev
> > > tag: 8.10.0-rc1
> > >
> > >
> > > Cheers,
> > > Tim
> > >
> > > -
> > > 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
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >

Re: [VOTE] Release Lucene/Solr 8.10.0 RC1

[Cassandra Targett]

Because when I tried to fix my initial mistake I only updated the HTML pages 
and thought I could skip updating the image dir but forgot there are new ones 
:-|

I’ll fix it now.
On Sep 22, 2021, 3:45 PM -0500, Timothy Potter , wrote:
> Thank you Cassandra! Any idea why the schema designer images are
> showing as broken links?
> https://solr.apache.org/guide/8_10/schema-designer.html ... the images
> are in images/schema-designer
>
> On Wed, Sep 22, 2021 at 2:31 PM Cassandra Targett  
> wrote:
> >
> > I uploaded the 8.10 Ref Guide to https://solr.apache.org/guide/8_10/ in 
> > DRAFT while we’re voting on the release.
> >
> > I accidentally first uploaded a version of the Ref Guide built on `main` 
> > branch back in March (a leftover from before the project split that didn’t 
> > get caught with `ant clean`). I’m confident I cleaned it up but please let 
> > me know if you see something that shouldn’t be there.
> > On Sep 22, 2021, 1:24 PM -0500, Jan Høydahl , wrote:
> >
> > +1
> >
> > SUCCESS! [1:09:04.477915]
> >
> > Just ran smoke tester.
> >
> > Jan
> >
> > 22. sep. 2021 kl. 17:41 skrev Timothy Potter :
> >
> > Please vote for release candidate 1 for Lucene/Solr 8.10.0
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> >
> > The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00 UTC.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here is my +1 (binding) SUCCESS! [0:56:24.357153]
> >
> >
> > Lastly, for those interested in kicking the tires on Solr using
> > Docker, I posted an *unofficial* Docker image built locally from the
> > RC to: thelabdude/apache-solr-dev:8.10.0-rc1
> >
> > We just released v0.4.0 of the Apache Solr Operator, so if you want to
> > try out this RC on Kubernetes, you can use the following YAML config
> > in your SolrCloud CR definition:
> >
> > solrImage:
> > repository: thelabdude/apache-solr-dev
> > tag: 8.10.0-rc1
> >
> >
> > Cheers,
> > Tim
> >
> > -
> > 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: [VOTE] Release Lucene/Solr 8.10.0 RC1

[Cassandra Targett]

I uploaded the 8.10 Ref Guide to https://solr.apache.org/guide/8_10/ in DRAFT 
while we’re voting on the release.

I accidentally first uploaded a version of the Ref Guide built on `main` branch 
back in March (a leftover from before the project split that didn’t get caught 
with `ant clean`). I’m confident I cleaned it up but please let me know if you 
see something that shouldn’t be there.
On Sep 22, 2021, 1:24 PM -0500, Jan Høydahl , wrote:
> +1
>
> SUCCESS! [1:09:04.477915]
>
> Just ran smoke tester.
>
> Jan
>
> > 22. sep. 2021 kl. 17:41 skrev Timothy Potter :
> >
> > Please vote for release candidate 1 for Lucene/Solr 8.10.0
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> >
> > The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00 UTC.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here is my +1 (binding) SUCCESS! [0:56:24.357153]
> >
> >
> > Lastly, for those interested in kicking the tires on Solr using
> > Docker, I posted an *unofficial* Docker image built locally from the
> > RC to: thelabdude/apache-solr-dev:8.10.0-rc1
> >
> > We just released v0.4.0 of the Apache Solr Operator, so if you want to
> > try out this RC on Kubernetes, you can use the following YAML config
> > in your SolrCloud CR definition:
> >
> > solrImage:
> > repository: thelabdude/apache-solr-dev
> > tag: 8.10.0-rc1
> >
> >
> > Cheers,
> > Tim
> >
> > -
> > 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: Release Lucene/Solr 8.9.0 should we have it soon

[Cassandra Targett]

It’s OK with me, but I’m not really in a position to understand the changes 
and/or test it. And while we have a branch, I’m not clear on when the first RC 
is planned, so Mayya should weigh in I think.

Cassandra
On Jun 3, 2021, 5:49 AM -0500, Jan Høydahl , wrote:
> Mayya, Cassandra, I'd like to merge the Jetty upgrade, SOLR-15316 to 
> branch_8x and branch_8_9. See backport PR 
> https://github.com/apache/lucene-solr/pull/2502
> Is that ok?
>
> Jan
>
> > 2. jun. 2021 kl. 01:00 skrev Jan Høydahl :
> >
> > Cassandra,
> >
> > Thanks for spotting the Jetty JIRA (SOLR-15316). I put up a quck PR for 
> > upgrading Jetty to 9.4.41.v20210516. Currently running all tests.
> > Due to the CVEs I think there should not be a new Solr release without this 
> > upgrade. I set fixVersion to 8.9 and kept the blocker. If anyone disagrees, 
> > speak out.
> >
> > There's always a risk of a new Jetty version introducing new bugs, but this 
> > is a minor version upgrade with (almost) exclusively bug fixes since 
> > 9.4.36, so I'm willing to take the risk if tests look good. Perhaps Jenkins 
> > gets a few test spins on main before the 8.9 release too. Whyt Mayya?
> >
> > Jan
> >
> > > 1. jun. 2021 kl. 23:04 skrev Cassandra Targett :
> > >
> > > I got a question this morning about some Jetty CVEs that look to be fixed 
> > > with Jetty 9.4.39, and there’s an issue marked as a Blocker (with no 
> > > version) to upgrade to that version. Is there time to do that for 8.9? Or 
> > > is it too high risk or would take too long? 
> > > https://issues.apache.org/jira/browse/SOLR-15316
> > >
> > > Sorry, I’m way behind on mailing lists and didn’t see the branch had been 
> > > cut already!
> > >
> > > Cassandra
> > > On Jun 1, 2021, 3:54 PM -0500, Jan Høydahl , wrote:
> > > > Let's not hold up the release due to this incomplete PR. It obviously 
> > > > needs more time for completion and there is always a new train to catch.
> > > > As far as I understand, Circuit breakers are pluggable, so anyone can 
> > > > configure their own implementation in the meantime?
> > > >
> > > > Jan
> > > >
> > > > > 1. jun. 2021 kl. 22:13 skrev Atri Sharma :
> > > > >
> > > > > I appreciate you fixing this and adding the new circuit breaker and 
> > > > > look forward to having it in the hands of our users soon.
> > > > >
> > > > > However, the current state of PR, with significant API churn for a 
> > > > > single change and overlapping code is not yet ready.
> > > > >
> > > > > If this is too much of a rework, I am happy to take the existing PR 
> > > > > and do the changes, post which I believe the PR should be close to 
> > > > > completion.
> > > > >
> > > > > Let me know if you need me to help, but unfortunately, the two 
> > > > > objections I raised are blockers, atleast until we establish that 
> > > > > they cannot be done away with.
> > > > >
> > > > >
> > > > > > On Wed, 2 Jun 2021, 01:37 Walter Underwood,  
> > > > > > wrote:
> > > > > > > I would appreciate a second opinion on the pull request. 
> > > > > > > Substantive issues have been resolved. At this point, the 
> > > > > > > discussion is about code style and coding standards. I don’t have 
> > > > > > > detailed knowledge about the Solr coding style, so I’d appreciate 
> > > > > > > another set of eyes.
> > > > > > >
> > > > > > > The current behavior is buggy, and we are not able to use it at 
> > > > > > > Chegg. The patch fixes those bugs.
> > > > > > >
> > > > > > > https://github.com/apache/solr/pull/96
> > > > > > >
> > > > > > > wunder
> > > > > > > Walter Underwood
> > > > > > > wun...@wunderwood.org
> > > > > > > http://observer.wunderwood.org/  (my blog)
> > > > > > >
> > > > > > > > On Jun 1, 2021, at 12:27 PM, Walter Underwood 
> > > > > > > >  wrote:
> > > > > > > >
> > > > > > > > I answered the comments. I don’t see those answers on github, 
> > > > > > > > oddly.
> > > > > > > >
> > 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Cassandra Targett]

I got a question this morning about some Jetty CVEs that look to be fixed with 
Jetty 9.4.39, and there’s an issue marked as a Blocker (with no version) to 
upgrade to that version. Is there time to do that for 8.9? Or is it too high 
risk or would take too long? https://issues.apache.org/jira/browse/SOLR-15316

Sorry, I’m way behind on mailing lists and didn’t see the branch had been cut 
already!

Cassandra
On Jun 1, 2021, 3:54 PM -0500, Jan Høydahl , wrote:
> Let's not hold up the release due to this incomplete PR. It obviously needs 
> more time for completion and there is always a new train to catch.
> As far as I understand, Circuit breakers are pluggable, so anyone can 
> configure their own implementation in the meantime?
>
> Jan
>
> > 1. jun. 2021 kl. 22:13 skrev Atri Sharma :
> >
> > I appreciate you fixing this and adding the new circuit breaker and look 
> > forward to having it in the hands of our users soon.
> >
> > However, the current state of PR, with significant API churn for a single 
> > change and overlapping code is not yet ready.
> >
> > If this is too much of a rework, I am happy to take the existing PR and do 
> > the changes, post which I believe the PR should be close to completion.
> >
> > Let me know if you need me to help, but unfortunately, the two objections I 
> > raised are blockers, atleast until we establish that they cannot be done 
> > away with.
> >
> >
> > > On Wed, 2 Jun 2021, 01:37 Walter Underwood,  wrote:
> > > > I would appreciate a second opinion on the pull request. Substantive 
> > > > issues have been resolved. At this point, the discussion is about code 
> > > > style and coding standards. I don’t have detailed knowledge about the 
> > > > Solr coding style, so I’d appreciate another set of eyes.
> > > >
> > > > The current behavior is buggy, and we are not able to use it at Chegg. 
> > > > The patch fixes those bugs.
> > > >
> > > > https://github.com/apache/solr/pull/96
> > > >
> > > > wunder
> > > > Walter Underwood
> > > > wun...@wunderwood.org
> > > > http://observer.wunderwood.org/  (my blog)
> > > >
> > > > > On Jun 1, 2021, at 12:27 PM, Walter Underwood  
> > > > > wrote:
> > > > >
> > > > > I answered the comments. I don’t see those answers on github, oddly.
> > > > >
> > > > > I’ll re-answer them. Most of your questions are already answered in 
> > > > > the discussion on Jira.
> > > > >
> > > > > I central issues is that load average is not always a CPU measure. In 
> > > > > some systems, it includes threads in iowait. So it is potentially 
> > > > > misleading to label it as CPU and document it as CPU. The updated 
> > > > > documentation makes that clear, so that should have already answered 
> > > > > your comment. that is why it is important to rename the existing 
> > > > > circuit breaker.
> > > > >
> > > > > wunder
> > > > > Walter Underwood
> > > > > wun...@wunderwood.org
> > > > > http://observer.wunderwood.org/  (my blog)
> > > > >
> > > > > > On Jun 1, 2021, at 12:20 PM, Atri Sharma  wrote:
> > > > > >
> > > > > > I tool a look at the PR and gave comments for SOLR-15056, and the 
> > > > > > last I checked, my comments were not addressed?
> > > > > >
> > > > > > > On Wed, 2 Jun 2021, 00:31 Walter Underwood, 
> > > > > > >  wrote:
> > > > > > > > Could someone else please take a look at SOLR-15056? This is a 
> > > > > > > > small blast radius change that improves the circuit breakers. 
> > > > > > > > It includes unit tests and documentation and has been ready 
> > > > > > > > since January.
> > > > > > > >
> > > > > > > > https://github.com/apache/solr/pull/96/files
> > > > > > > > https://issues.apache.org/jira/browse/SOLR-15056
> > > > > > > >
> > > > > > > > wunder
> > > > > > > > Walter Underwood
> > > > > > > > wun...@wunderwood.org
> > > > > > > > http://observer.wunderwood.org/  (my blog)
> > > > > > > >
> > > > > > > > > On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Thank you for the update, Houston.
> > > > > > > > >
> > > > > > > > > I've started the release process, the branch 8.9 is now cut.
> > > > > > > > >
> > > > > > > > > > On Tue, Jun 1, 2021 at 11:21 AM Houston Putman 
> > > > > > > > > >  wrote:
> > > > > > > > > > > Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
> > > > > > > > > > >
> > > > > > > > > > > - Houston
> > > > > > > > > > >
> > > > > > > > > > > > On Thu, May 27, 2021 at 11:42 PM David Smiley 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > SOLR-15412 is rather serious as the title suggests.  
> > > > > > > > > > > > > I haven't been tracking the progress so if it's 
> > > > > > > > > > > > > already resolved, that's unknown to me and isn't 
> > > > > > > > > > > > > reflected in JIRA.
> > > > > > > > > > > > >
> > > > > > > > > > > > > ~ David Smiley
> > > > > > > > > > > > > Apache Lucene/Solr Search Developer
> > > > > > > > > > > > > http://www.linkedin.com/in/davidwsmiley
> > > > > > > > > > > > >
> > > > > > > > 

Re: Bugfix release Lucene/Solr 8.8.2

[Cassandra Targett]

Oh, I see what you meant! I actually just redid the changes from scratch 
instead of trying to backport the 9.0 changes as a patch, so no worries on that 
front. Thanks for thinking of me there though!

I just committed some changes for morelikethis.adoc that I decided I’d like to 
backport into branch_8_8 since we’re re-publishing…it’s docs-only, though.
On Mar 29, 2021, 2:25 PM -0500, Mike Drob , wrote:
> Thanks, Cassandra. When I skimmed the initial changeset, I saw that there 
> were changes to build.gradle - I assumed that there would have to be some 
> changes to build.xml in the 8x branch, but I didn't investigate further on 
> how they would differ. Was just trying to be helpful and give you a heads up 
> about it, but looks like I caused more confusion than help!
>
> > On Mon, Mar 29, 2021 at 1:31 PM Cassandra Targett  
> > wrote:
> > > I pushed up the URL changes I mentioned.
> > >
> > > Not sure what you mean, Mike, by “gradle->ant translation”? The build 
> > > process is different in branch_8x but it’s documented in the 
> > > how-to-contribute page in the ref guide that talks about contributing and 
> > > building, etc.
> > > On Mar 29, 2021, 12:55 PM -0500, Mike Drob , wrote:
> > > >
> > > > Cassandra - yes, I plan to republish the ref guide, your expertise is 
> > > > absolutely appreciated. It looks like there will also be some 
> > > > gradle->ant translation. Was this mostly find-and-replace or was there 
> > > > more order to it?
> > > >
> > > > On Mon, Mar 29, 2021 at 12:32 PM Alan Woodward  
> > > > wrote:
> > > > > Hi Mike,
> > > > >
> > > > > I’d like to back port LUCENE-9744 (which fixes an NPE in intervals 
> > > > > queries) and LUCENE-9762 (which fixes a bug in QueryValuesSource).
> > > > >
> > > > > Thanks, Alan
> > > > >
> > > > > > On 29 Mar 2021, at 09:47, Ignacio Vera  wrote:
> > > > > >
> > > > > > I'd like to backport Lucene-9870 which is a bug in distance queries 
> > > > > > that causes no matches along indexed lines and polygon edges. This 
> > > > > > fix only touches one class tho so very low risk.
> > > > > >
> > > > > > lucene
> > > > > >
> > > > > > On Sat, Mar 27, 2021 at 3:24 PM Mike Drob  wrote:
> > > > > > > Ishan,
> > > > > > >
> > > > > > > Thank you for bringing this up. I’m comfortable delaying an extra 
> > > > > > > week to accommodate the multitude of holidays (Holi, Passover, 
> > > > > > > others) coming up.
> > > > > > >
> > > > > > > I will adjust my schedule to start the vote Tuesday, Apr 6.
> > > > > > >
> > > > > > > Please make sure that all back ports are appropriately marked 
> > > > > > > with fixVersion in Jira and have corresponding CHANGES entries.
> > > > > > >
> > > > > > > Mike
> > > > > > >
> > > > > > > On Fri, Mar 26, 2021 at 11:11 PM Ishan Chattopadhyaya 
> > > > > > >  wrote:
> > > > > > > > Hi Mike,
> > > > > > > >
> > > > > > > > I wish to get https://issues.apache.org/jira/browse/SOLR-15288 
> > > > > > > > in, but will likely be able to wrap up by 2 April or so (on 
> > > > > > > > vacation right now due to the festival of Holi)
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ishan
> > > > > > > >
> > > > > > > > On Sat, 27 Mar, 2021, 7:41 am Mike Drob,  
> > > > > > > > wrote:
> > > > > > > > > I am now preparing for a bugfix release from branch branch_8_8
> > > > > > > > >
> > > > > > > > > I plan to have the RC built and vote started on Tuesday, Mar 
> > > > > > > > > 30. If you have small, low risk bug fixes to backport before 
> > > > > > > > > then, please do so using your best judgement.
> > > > > > > > >
> > > > > > > > > Please observe the normal rules for committing to this branch:
> > > > > > > > >
> > > > > > > > > * Before committing to the branch, reply to this thread and 
> > > > > > > > > argue
> > > > > > > > >   why the fix needs backporting and how long it will take.
> > > > > > > > > * All issues accepted for backporting should be marked with 
> > > > > > > > > 8.8.2
> > > > > > > > >   in JIRA, and issues that should delay the release must be 
> > > > > > > > > marked as Blocker
> > > > > > > > > * All patches that are intended for the branch should first 
> > > > > > > > > be committed
> > > > > > > > >   to the unstable branch, merged into the stable branch, and 
> > > > > > > > > then into
> > > > > > > > >   the current release branch.
> > > > > > > > > * Only Jira issues with Fix version 8.8.2 and priority 
> > > > > > > > > "Blocker" will delay
> > > > > > > > >   a release candidate build.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Mike
> > > > >

Re: Bugfix release Lucene/Solr 8.8.2

[Cassandra Targett]

I pushed up the URL changes I mentioned.

Not sure what you mean, Mike, by “gradle->ant translation”? The build process 
is different in branch_8x but it’s documented in the how-to-contribute page in 
the ref guide that talks about contributing and building, etc.
On Mar 29, 2021, 12:55 PM -0500, Mike Drob , wrote:
>
> Cassandra - yes, I plan to republish the ref guide, your expertise is 
> absolutely appreciated. It looks like there will also be some gradle->ant 
> translation. Was this mostly find-and-replace or was there more order to it?
>
> On Mon, Mar 29, 2021 at 12:32 PM Alan Woodward  wrote:
> > Hi Mike,
> >
> > I’d like to back port LUCENE-9744 (which fixes an NPE in intervals queries) 
> > and LUCENE-9762 (which fixes a bug in QueryValuesSource).
> >
> > Thanks, Alan
> >
> > > On 29 Mar 2021, at 09:47, Ignacio Vera  wrote:
> > >
> > > I'd like to backport Lucene-9870 which is a bug in distance queries that 
> > > causes no matches along indexed lines and polygon edges. This fix only 
> > > touches one class tho so very low risk.
> > >
> > > lucene
> > >
> > > On Sat, Mar 27, 2021 at 3:24 PM Mike Drob  wrote:
> > > > Ishan,
> > > >
> > > > Thank you for bringing this up. I’m comfortable delaying an extra week 
> > > > to accommodate the multitude of holidays (Holi, Passover, others) 
> > > > coming up.
> > > >
> > > > I will adjust my schedule to start the vote Tuesday, Apr 6.
> > > >
> > > > Please make sure that all back ports are appropriately marked with 
> > > > fixVersion in Jira and have corresponding CHANGES entries.
> > > >
> > > > Mike
> > > >
> > > > On Fri, Mar 26, 2021 at 11:11 PM Ishan Chattopadhyaya 
> > > >  wrote:
> > > > > Hi Mike,
> > > > >
> > > > > I wish to get https://issues.apache.org/jira/browse/SOLR-15288 in, 
> > > > > but will likely be able to wrap up by 2 April or so (on vacation 
> > > > > right now due to the festival of Holi)
> > > > >
> > > > > Regards,
> > > > > Ishan
> > > > >
> > > > > On Sat, 27 Mar, 2021, 7:41 am Mike Drob,  wrote:
> > > > > > I am now preparing for a bugfix release from branch branch_8_8
> > > > > >
> > > > > > I plan to have the RC built and vote started on Tuesday, Mar 30. If 
> > > > > > you have small, low risk bug fixes to backport before then, please 
> > > > > > do so using your best judgement.
> > > > > >
> > > > > > Please observe the normal rules for committing to this branch:
> > > > > >
> > > > > > * Before committing to the branch, reply to this thread and argue
> > > > > >   why the fix needs backporting and how long it will take.
> > > > > > * All issues accepted for backporting should be marked with 8.8.2
> > > > > >   in JIRA, and issues that should delay the release must be marked 
> > > > > > as Blocker
> > > > > > * All patches that are intended for the branch should first be 
> > > > > > committed
> > > > > >   to the unstable branch, merged into the stable branch, and then 
> > > > > > into
> > > > > >   the current release branch.
> > > > > > * Only Jira issues with Fix version 8.8.2 and priority "Blocker" 
> > > > > > will delay
> > > > > >   a release candidate build.
> > > > > >
> > > > > > Thanks,
> > > > > > Mike
> >

Re: Bugfix release Lucene/Solr 8.8.2

[Cassandra Targett]

You mentioned maybe re-publishing the Ref Guide in one of the issues, do you 
still want to do that? If so, I should backport URL changes for the project 
split (https://issues.apache.org/jira/browse/SOLR-15212) - it won’t be a 
problem for me to do that before the end of this week.
On Mar 29, 2021, 3:47 AM -0500, Ignacio Vera , wrote:
> I'd like to backport Lucene-9870 which is a bug in distance queries that 
> causes no matches along indexed lines and polygon edges. This fix only 
> touches one class tho so very low risk.
> lucene
>
> > On Sat, Mar 27, 2021 at 3:24 PM Mike Drob  wrote:
> > > Ishan,
> > >
> > > Thank you for bringing this up. I’m comfortable delaying an extra week to 
> > > accommodate the multitude of holidays (Holi, Passover, others) coming up.
> > >
> > > I will adjust my schedule to start the vote Tuesday, Apr 6.
> > >
> > > Please make sure that all back ports are appropriately marked with 
> > > fixVersion in Jira and have corresponding CHANGES entries.
> > >
> > > Mike
> > >
> > > > On Fri, Mar 26, 2021 at 11:11 PM Ishan Chattopadhyaya 
> > > >  wrote:
> > > > > Hi Mike,
> > > > >
> > > > > I wish to get https://issues.apache.org/jira/browse/SOLR-15288 in, 
> > > > > but will likely be able to wrap up by 2 April or so (on vacation 
> > > > > right now due to the festival of Holi)
> > > > >
> > > > > Regards,
> > > > > Ishan
> > > > >
> > > > > > On Sat, 27 Mar, 2021, 7:41 am Mike Drob,  wrote:
> > > > > > > I am now preparing for a bugfix release from branch branch_8_8
> > > > > > >
> > > > > > > I plan to have the RC built and vote started on Tuesday, Mar 30. 
> > > > > > > If you have small, low risk bug fixes to backport before then, 
> > > > > > > please do so using your best judgement.
> > > > > > >
> > > > > > > Please observe the normal rules for committing to this branch:
> > > > > > >
> > > > > > > * Before committing to the branch, reply to this thread and argue
> > > > > > >   why the fix needs backporting and how long it will take.
> > > > > > > * All issues accepted for backporting should be marked with 8.8.2
> > > > > > >   in JIRA, and issues that should delay the release must be 
> > > > > > > marked as Blocker
> > > > > > > * All patches that are intended for the branch should first be 
> > > > > > > committed
> > > > > > >   to the unstable branch, merged into the stable branch, and then 
> > > > > > > into
> > > > > > >   the current release branch.
> > > > > > > * Only Jira issues with Fix version 8.8.2 and priority "Blocker" 
> > > > > > > will delay
> > > > > > >   a release candidate build.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Mike

Re: Solr webpage SEO

[Cassandra Targett]

For the Ref Guide a good amount of the traffic is probably the old redirect 
rules in Confluence that explicitly went to 6_6 for a good reason *at the 
time*. A blanket fix to those rules (it was a discrete list of pages in a text 
file) to remove the URL in the path would cause them to be automatically 
redirected to the latest. I’d honestly be fine just removing the redirect rules 
entirely…it’s been almost 4 years, when do we get to move on?

A lot of the 6.6 traffic is also coming from Google itself since that version 
of a page frequently appears at the top of search results, possibly at least 
partially due to that Confluence redirect rule, but I’m sure there are also 
other factors. IIRC people have proposed general ideas about how to fix that, 
but I don’t recall seeing actual code or PRs yet to actually address the issue.
On Mar 4, 2021, 5:34 AM -0600, Uwe Schindler , wrote:
> I disagree with excluding older Java docs or refguide using robots! When I 
> look for documentation of a class I generally enter class name and version 
> number into google.
>
> We can maybe handle this with priorities inside a sitemap.xml or custom http 
> headers (X-Robots) using a htaccess rule. I can check this out.
>
> Uwe
>
> Am March 4, 2021 10:41:52 AM UTC schrieb "Jan Høydahl" 
> :
> > Sure we could do robots.
> >
> > But I suspect that we put ourselves in this situation through 
> > https://issues.apache.org/jira/browse/SOLR-10595 ourselves
> > Check out the attachment solr_redirects.conf on that JIRA (also here 
> > https://gist.github.com/janhoy/a3149e1ed27df020194a2de1a7fa2c16)
> >
> > Here, we explicitly map all pages that used to be in Confluence (which 
> > there are a ton of links to on the net), to version 6.6 of the guide.
> > Of course, if we change those to "latest", some of those links will break, 
> > but perhaps it would still be better?
> > Or can we be more intelligent in the rewrite rules on Solr site - that if 
> > you try a "/guide/foo.html" link and it is not found, that you display a 
> > custom error page or go to front page of latest guide?
> >
> > Jan
> >
> > > 4. mar. 2021 kl. 10:21 skrev Ishan Chattopadhyaya 
> > > :
> > >
> > > We can add robots.txt to stop Google from indexing/showing in results.
> > >
> > > On Thu, 4 Mar, 2021, 2:34 pm Jan Høydahl,  wrote:
> > > > Hi, sending to this list since dev@solr list is not yet announced 
> > > > properly.
> > > >
> > > >  We have a few days of traffic to the new site and can see the most 
> > > > visited pages at https://uls.apache.org/exports/solr.apache.org.yaml 
> > > > (see copy below).
> > > > When I search google for "solr query parser", I get the 6.6 guide on 
> > > > top, which is probably why /guide/6_6/the-standard-query-parser.html 
> > > > shows up, and the same for the other /guide/6_6/ links.
> > > > Some questions:
> > > >
> > > >  • How can we make Google forget about version 6.6? I know we had a 
> > > > bunch of redirects from Confluence to the 6.6 guide, are they still in 
> > > > place?
> > > >  • Why is /docs/6_6_0/solr-core/index.html the 2nd most visited page? 
> > > > Anywhere that links to it?
> > > >  • Why is /docs/4_8_1/solr-solrj/index.html so high? Ahywhere that 
> > > > links to it?
> > > >  • The /mirrors-solr-latest-redir.html redirect was not working. I just 
> > > > pushed a fix
> > > >
> > > >
> > > > Sheet3:
> > > >   Name: Most visited pages, past month
> > > >   Values:
> > > >     /index.html: 443
> > > >     /docs/6_6_0/solr-core/index.html: 281
> > > >     /guide/8_8/solr-tutorial.html: 104
> > > >     /news.html: 92
> > > >     /guide/solr-tutorial.html: 91
> > > >     /resources.html: 75
> > > >     /features.html: 69
> > > >     /docs/8_7_0/solr-core/index.html: 68
> > > >     /downloads.html: 68
> > > >     /guide/6_6/the-standard-query-parser.html: 65
> > > >     /docs/4_8_1/solr-solrj/index.html: 62
> > > >     /guide/6_6/common-query-parameters.html: 50
> > > >     /guide/index.html: 46
> > > >     /docs/8_8_1/solr-solrj/index.html: 44
> > > >     /docs/8_7_0/solr-solrj/index.html: 38
> > > >     /docs/8_8_1/solr-core/index.html: 37
> > > >     /community.html: 24
> > > >     /guide/8_8/: 23
> > > >     /guide/6_6/uploading-data-with-index-handlers.html: 22
> > > >     /docs/8_6_3/solr-core/index.html: 21
> > > >     /guide/6_6/filter-descriptions.html: 21
> > > >     /guide/6_6/collections-api.html: 18
> > > >     /docs/8_6_2/solr-solrj/overview-summary.html: 16
> > > >     /guide/6_6/faceting.html: 16
> > > >     /mirrors-solr-latest-redir.html: 15
> > > >     /whoweare.html: 15
> > > >     /guide/6_6/solrcloud.html: 14
> > > >     /guide/6_6/tokenizers.html: 13
> > > >     /guide/7_0/solr-configuration-files.html: 13
> > > >     /guide/8_8/query-syntax-and-parsing.html: 13
> > > >     /security.html: 13
> > > >     /guide/6_6/introduction-to-solr-indexing.html: 12
> > > >     /guide/8_8/solr-upgrade-notes.html: 12
> > > >     /docs/8_0_0/solr-solrj/allclasses-frame.html: 11
> > > >     

Re: JIRA issues to close?

[Cassandra Targett]

At times in the past (maybe still) there have been lots of issues with a 
released fix version which are marked as Open, Reopened, or Patch Available. 
It’s just not a thing we monitor or correct very comprehensively so those 
issues are very likely still open and should not be closed.

To be sure a bulk edit such as this does not close things that should really be 
open, the query should stick to things that are marked Resolved only.
On Feb 18, 2021, 2:35 PM -0600, Alexandre Rafalovitch , 
wrote:
> You may enjoy using JiraSearch for this kinds of things, it has a very
> nice "Updated Ago >x", and "Last comment user" facet and 'shift-click'
> multi-select on status:
> http://jirasearch.mikemccandless.com/
>
> For the bulk changes, from the screen you are at, you click on Tools
> near top-right area of the screen and select "screen" or "1000" and
> that's the beginning of the process. Makes sure to unselect "notify
> everybody" box on the last (2nd last?) screen or a lot of people will
> be upset.
>
> But also, we had less than fantastic history with bulk closing (had to
> reopen/revert). So, it may be better to focus on a very small, clearly
> "done" subset and/or leave quick notes "can this be closed" with a
> follow-up to close.
>
> Regards,
> Alex.
>
> On Thu, 18 Feb 2021 at 14:43, Eric Pugh  
> wrote:
> >
> > I’m still learning my way around JIRA, and I was looking for a Solr JIRA 
> > that I swear I had seen open recently. In trying to query for open/active 
> > JIRAs, I crafted this query, which returned a lot of tickets that I *think* 
> > should be CLOSED at this point:
> >
> > https://issues.apache.org/jira/browse/SOLR-13394?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Open%2C%20Reopened%2C%20Resolved%2C%20%22Patch%20Available%22)%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20in%20releasedVersions()
> >
> > There are 1102 tickets that appear to be old dealt with tickets and should 
> > be CLOSED.
> >
> > I wanted to point that out, and see if someone could move them to CLOSED, 
> > or point me to how to do the Bulk Close that I’ve seen happen periodically 
> > over the years.
> >
> > Eric
> >
> > ___
> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> > http://www.opensourceconnections.com | My Free/Busy
> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> > This e-mail and all contents, including attachments, is considered to be 
> > Company Confidential unless explicitly stated otherwise, regardless of 
> > whether attachments are marked as such.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: Confusion over the term "paramsets" and "Request Parameters API" in Ref Guide

[Cassandra Targett]

I have a slightly different view - the thing that creates a paramset, stored in 
a file called params.json, is called the Request Params API, primarily driven 
by RequestParams.java, which is why the page is called that. The discrepancy 
between the naming of the API and the thing it creates has caused this 
confusion.

The name of the API is in fact more precise than the thing it creates - it’s 
for request parameters, not other general parameters found in other contexts - 
while the thing it creates is a shorthand name.

All that’s not to say I object to the change. Just that it wasn’t done the way 
it is without some thought having gone into it. I honestly just wish the thing 
“paramsets” was called something else.

(I frankly loathe the tendency to always shorthand “parameters” as “params” in 
documentation. I’m the one who changed it from being the Request Params API to 
the Request Parameters API and otherwise did the best I could with the fact 
that the file is named “params.json” and not “request-params.json” or something 
similarly more precise to its functionality.)

A few things:

While we’re changing things, is a code change warranted to make the name of the 
thing “paramsets" more clear in terms of scope? Just throwing it out there.

Usually we don’t just rename pages entirely - there is no 404 redirect 
mechanism currently in place, so users who may have figured out that the 
Request Parameters API page = paramsets (as functionality) would find a 404 in 
the docs from 8.9 forward. Do we care? (At the same time, though, we’re going 
to need to address this eventually as I have a long list of page renames coming 
for 9.0.)

Settle on “paramSets” or “paramsets” or “ParamSets” - you used it 2 different 
ways in your mail alone. It should be one way always.
On Feb 8, 2021, 12:02 PM -0600, Erik Hatcher , wrote:
>
>
> > On Feb 6, 2021, at 9:48 AM, Eric Pugh  
> > wrote:
> >
> > “paramsets”, which I think is a really powerful feature that most people 
> > don’t know about.
>
> Agreed on that! (see the old example/files for my early paramset usage as I 
> explored that cool capability)
>
> > I’m thinking that we rename request-parameters-api.adoc —> paramsets.adoc, 
> > and rewrite the page to highlight that this feature is called “paramset”, 
> > in the same way we use the term “configset”.
>
> +1
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Cassandra Targett]

Just so everyone is aware, an accidental commit as part of the 8.8 release 
process that Noble was working on removed all the Lucene Javadocs, Solr 
Javadocs, and Solr Ref Guides for the 8.5.0 through 8.8.0 releases from the SVN 
production repo where they are served from.

I talked to Noble about it in Slack 
(https://the-asf.slack.com/archives/CEKUCUNE9/p1611931168079700) and I think we 
pinpointed the commit that did it. As it’s quite late in Australia now, he said 
he will work on fixing it in his morning so he can be sure he doesn’t mess it 
up further.

I thought I’d let everyone know in case others notice today that these versions 
are missing.

Cassandra
On Jan 29, 2021, 8:46 AM -0600, Noble Paul , wrote:
> Yes, if someone is willing to invest time to fix the failures we
> should. totally do it.
>
> Unfortunately, I don't see anyone making that investment
>
>
> On Sat, Jan 30, 2021 at 12:12 AM Jason Gerlowski  
> wrote:
> >
> > I agree with Noble that we shouldn't let those flakies hold up the
> > release. It really sucks, but Solr wouldn't've gotten out a release in
> > years if that was our bar.
> >
> > FWIW though I disagree with his finer point that we shouldn't worry
> > about autoscaling in particular because it's slated for removal in
> > 9.0. We're not releasing 9.0, we're releasing 8.8. And there's
> > likely to be an 8.8.1 or 8.9 at some point later. So there's
> > definitely a "point in trying to fix" those failures, generally
> > speaking.
> >
> > Jason
> >
> > On Thu, Jan 28, 2021 at 6:01 PM Noble Paul  wrote:
> > >
> > > I'm not sure why the tests fail. But, there is no point in trying to
> > > fix them if that code is removed from master and we do not plan to
> > > support them anyway
> > >
> > > On Fri, Jan 29, 2021 at 9:43 AM David Smiley  
> > > wrote:
> > > >
> > > > Ah; I see they appear to be 8x only. Any idea what the story is with 
> > > > them? Do you think it is just test flakiness or flakiness in Solr's 
> > > > related functionality?
> > > >
> > > > ~ David
> > > >
> > > >
> > > > On Thu, Jan 28, 2021 at 5:36 PM Noble Paul  wrote:
> > > > >
> > > > > Both of those are gone for good @David Smiley I think we can safely
> > > > > make them BadApples
> > > > >
> > > > > On Fri, Jan 29, 2021 at 9:07 AM David Smiley  
> > > > > wrote:
> > > > > >
> > > > > > I ran it twice on my old-ish MacBook, and it failed each time on 
> > > > > > Solr tests that have a history of flakiness (as shown by Hossman's 
> > > > > > awesome fucit.org site) -- AutoscalingHistoryHandlerTest & 
> > > > > > TestWithCollection. Neither seed repeated. I'll pass on voting.
> > > > > >
> > > > > > ~ David Smiley
> > > > > > Apache Lucene/Solr Search Developer
> > > > > > http://www.linkedin.com/in/davidwsmiley
> > > > > >
> > > > > >
> > > > > > On Thu, Jan 28, 2021 at 11:35 AM Cassandra Targett 
> > > > > >  wrote:
> > > > > > >
> > > > > > > I’ve updated the Ref Guide to remove the DRAFT status on 8.8 
> > > > > > > pages, so that’s done. I’ll also take care of the next Ref Guide 
> > > > > > > step to update the website to show 8.8 as the latest.
> > > > > > > On Jan 28, 2021, 9:59 AM -0600, Tomás Fernández Löbbe 
> > > > > > > , wrote:
> > > > > > >
> > > > > > > It’s 9 binding: Noble, Tim, me, Ignacio, Mike M, Namgyu, Atri, 
> > > > > > > Anshum and Mike S.
> > > > > > >
> > > > > > > 1 non-binding: Haoyu
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jan 28, 2021 at 5:34 AM Michael Sokolov 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > SUCCESS! [0:58:25.213071]
> > > > > > > >
> > > > > > > > +1 better late than never?
> > > > > > > >
> > > > > > > > On Thu, Jan 28, 2021 at 8:04 AM Ishan Chattopadhyaya
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Thanks Noble!
> > > > > > > > >
> > > >

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Cassandra Targett]

I’ve updated the Ref Guide to remove the DRAFT status on 8.8 pages, so that’s 
done. I’ll also take care of the next Ref Guide step to update the website to 
show 8.8 as the latest.
On Jan 28, 2021, 9:59 AM -0600, Tomás Fernández Löbbe , 
wrote:
> It’s 9 binding: Noble, Tim, me, Ignacio, Mike M, Namgyu, Atri, Anshum and 
> Mike S.
> 1 non-binding: Haoyu
>
> > On Thu, Jan 28, 2021 at 5:34 AM Michael Sokolov  wrote:
> > > SUCCESS! [0:58:25.213071]
> > >
> > > +1 better late than never?
> > >
> > > On Thu, Jan 28, 2021 at 8:04 AM Ishan Chattopadhyaya
> > >  wrote:
> > > >
> > > > Thanks Noble!
> > > >
> > > > On Thu, 28 Jan, 2021, 4:24 pm Noble Paul,  wrote:
> > > >>
> > > >> [+1]  9  (4 binding)
> > > >>
> > > >>  [0]  0
> > > >>
> > > >> [-1]  0
> > > >>
> > > >>
> > > >> This vote has PASSED.
> > > >>
> > > >> I shall proceed with the rest of the release process
> > > >>
> > > >> On Thu, Jan 28, 2021 at 6:24 PM Anshum Gupta  
> > > >> wrote:
> > > >> >
> > > >> > Thanks for handing the release, Noble!
> > > >> >
> > > >> > +1 (binding)
> > > >> >
> > > >> > SUCCESS! [0:56:12.016387]
> > > >> >
> > > >> > Ran the smoke tester, a demo app, and checked the change log. All of 
> > > >> > that looks good.
> > > >> >
> > > >> > On Mon, Jan 25, 2021 at 2:22 AM Noble Paul  
> > > >> > wrote:
> > > >> >>
> > > >> >> Please vote for release candidate 2 for Lucene/Solr 8.8.0
> > > >> >>
> > > >> >> The artifacts can be downloaded from:
> > > >> >>
> > > >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
> > > >> >>
> > > >> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> > > >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> The vote will be open for at least 72 hours
> > > >> >>
> > > >> >> [ ] +1  approve
> > > >> >> [ ] +0  no opinion
> > > >> >> [ ] -1  disapprove (and reason why)
> > > >> >>
> > > >> >> Here is my +1
> > > >> >> --
> > > >> >> -
> > > >> >> Noble Paul
> > > >> >>
> > > >> >> -
> > > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> > > >> >>
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Anshum Gupta
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> -
> > > >> Noble Paul
> > > >>
> > > >> -
> > > >> 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: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Cassandra Targett]

I’ve put up the DRAFT version of the Ref Guide for 8.8: 
https://lucene.apache.org/solr/guide/8_8/.

I also created the Jenkins job for building the 8.8 guide which pushes to the 
Nightlies server in case we have edits between now and release 
(https://nightlies.apache.org/Lucene/Solr-reference-guide-8.8/).

Note branch_8_8 does not (yet) include the new Math Expressions guide being 
worked on in SOLR-13105. Still hoping that will make it, but thought I’d get 
this out sooner rather than later just in case.
On Jan 19, 2021, 10:51 AM -0600, Ishan Chattopadhyaya 
, wrote:
> Please vote for release candidate 1 for Lucene/Solr 8.8.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>
> The vote will be open for at least 72 hours i.e. until 2021-01-22 17:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> 

Re: https://lucene.apache.org/solr/guide/ needs to be updated on each release

[Cassandra Targett]

Yes, I’ve always done it. For 8.7 I think Atri took it on himself to do it (I’m 
really not totally sure, though, even 3 months ago feels like a different 
century). I don’t mind doing it, but there’s no reason why a RM couldn’t do it. 
However, I don’t think I have the skills to update the release wizard to add 
the tasks.
On Jan 14, 2021, 4:45 PM -0600, Jan Høydahl , wrote:
> I don’t find it in the releaseWizard. Guess the guide was always released 
> separately some time after the main release, but perhaps it’s time for the RM 
> to do the job?
>
> Jan Høydahl
>
> > 14. jan. 2021 kl. 21:00 skrev Cassandra Targett :
> >
> > This is in the “how to publish the ref guide” docs [1], but not sure it’s 
> > in any docs a RM follows, and I can’t remember if Atri pushed the final 
> > version for the 8.7 release or if I did it and forgot this step.
> >
> > At any rate, I’ll do it now just to fix it.
> >
> > [1] 
> > https://lucene.apache.org/solr/guide/8_7/how-to-contribute.html#publish-the-final-guide
> > On Jan 14, 2021, 3:35 AM -0600, Ishan Chattopadhyaya 
> > , wrote:
> > > @Atri Sharma FYI
> > >
> > > > On Thu, Jan 14, 2021 at 2:58 PM Colvin Cowie 
> > > >  wrote:
> > > > > I've just noticed https://lucene.apache.org/solr/guide/ says 8.6 is 
> > > > > the latest release and doesn't mention 8.7
> > > > > Latest release:
> > > > >
> > > > > • Solr 8.6
> > > > >

Re: https://lucene.apache.org/solr/guide/ needs to be updated on each release

[Cassandra Targett]

This is in the “how to publish the ref guide” docs [1], but not sure it’s in 
any docs a RM follows, and I can’t remember if Atri pushed the final version 
for the 8.7 release or if I did it and forgot this step.

At any rate, I’ll do it now just to fix it.

[1] 
https://lucene.apache.org/solr/guide/8_7/how-to-contribute.html#publish-the-final-guide
On Jan 14, 2021, 3:35 AM -0600, Ishan Chattopadhyaya 
, wrote:
> @Atri Sharma FYI
>
> > On Thu, Jan 14, 2021 at 2:58 PM Colvin Cowie  
> > wrote:
> > > I've just noticed https://lucene.apache.org/solr/guide/ says 8.6 is the 
> > > latest release and doesn't mention 8.7
> > > Latest release:
> > >
> > > • Solr 8.6
> > >

Re: [VOTE] Release Lucene/Solr 8.7.0 RC1

[Cassandra Targett]

I’m really late to the party since I was offline for the weekend and catching 
up yesterday, but the Draft Ref Guide for 8.7 is up (late): 
https://lucene.apache.org/solr/guide/8_7/

I’ll update to the final version when it’s released, I should have plenty of 
time for that in the back half of this week.
On Nov 2, 2020, 1:35 PM -0600, Anshum Gupta , wrote:
> Late to the party but
>
> +1 (binding)
>
> SUCCESS! [1:04:05.374710]
>
> Tried basic indexing and search and everything seems to be working as 
> expected.
>
> -Anshum
>
>
>
> > On Thu, Oct 29, 2020 at 9:54 PM Atri Sharma  wrote:
> > > Please vote for release candidate 1 for Lucene/Solr 8.7.0
> > >
> > >
> > > The artifacts can be downloaded from:
> > >
> > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.7.0-RC1-rev2dc63e901c60cda27ef3b744bc554f1481b3b067
> > >
> > >
> > > You can run the smoke tester directly with this command:
> > >
> > >
> > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > >
> > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.7.0-RC1-rev2dc63e901c60cda27ef3b744bc554f1481b3b067
> > >
> > >
> > > The vote will be open for at least 72 hours i.e. until 2020-11-01 20:00 
> > > UTC.
> > >
> > >
> > > [ ] +1  approve
> > >
> > > [ ] +0  no opinion
> > >
> > > [ ] -1  disapprove (and reason why)
> > >
> > >
> > > Here is my +1
> > >
> > > 
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > Apache Concerted
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
>
>
> --
> Anshum Gupta

Old Wiki re-org/cleanup

[Cassandra Targett]

Hi all -

I’m going to do a bit of moving of stuff around from the old Solr wiki so it’s 
easier to get a sense for what content we may still care about. There are a 
couple main things I’ll do (in the SOLR space only):

— Move pages with content that’s migrated to the Ref Guide to be a child of a 
new page “Moved to Ref Guide” (even if the page doesn’t say that yet)
— Move all the release notes for 5.0 and higher out of the “old wiki” page 
structure to live with our more recent release notes (nested probably by major 
version)

I won’t get it all done today or even this week, but will probably work on it 
in spurts.

I mention this just as a heads up that if you’ve subscribed to email 
notifications for every change in the SOLR space in cwiki, you’re about to get 
kind of spammed.

Cassandra

Re: 8.6.3 Release

[Cassandra Targett]

That’s a fair thing to consider, but does it really matter if someone looks at 
the draft notes pre-release? What would be the harm if users happen across them 
before they’re done?

(And to David’s point, it’s not in the RM steps to fix the page name after 
release, so it’s pretty easy to forget to do it.)
On Oct 22, 2020, 8:31 AM -0500, Atri Sharma , wrote:
> I added it since it looked a safe way to indicate that the draft notes
> are in progress and should not be referred to in case somebody is
> surfing the release notes.
>
> Atri
>
> On Thu, Oct 22, 2020 at 6:23 PM David Smiley  wrote:
> >
> > Jason: This is the first time I recall seeing release note pages in 
> > Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed 
> > suit (following your lead, no doubt) for 8.6. Why? Looking at the page 
> > navigation, it's clearly an oddity -- a change. And it's still DRAFT 
> > despite it being released.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski  
> > wrote:
> > >
> > > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> > > someone please sanity check the summaries there when they get a
> > > chance? Would appreciate the review.
> > >
> > > 8.6.3 is a bit interesting in that Lucene has no changes in this
> > > bugfix release. As a result I had to omit the standard phrase in the
> > > Solr release notes about there being additional changes at the Lucene
> > > level, and change some of the wording in the Lucene announcement to
> > > indicate the lack of changes. So that's something to pay particular
> > > attention to, if someone can check my wording there.
> > >
> > > [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> > > [2] 
> > > https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
> > >
> > > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
> > > wrote:
> > > >
> > > > The only one that was previously mentioned as a blocker was
> > > > SOLR-14835, but from the comments on the ticket it looks like it ended
> > > > up being purely a cosmetic issue. Andrzej left a comment there
> > > > suggesting that we "address" this with documentation for 8.6.3 but
> > > > otherwise leave it as-is.
> > > >
> > > > So it looks like we're unblocked on starting the release process.
> > > > Will begin the preliminary steps this afternoon.
> > > >
> > > > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett 
> > > >  wrote:
> > > > >
> > > > > It looks to me like everything for 8.6.3 is resolved now 
> > > > > (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and 
> > > > > it seems from comments in SOLR-14897 and SOLR-14898 that those fixes 
> > > > > make a Jetty upgrade less compelling to try.
> > > > >
> > > > > Are there any other issues not currently marked for 8.6.3 we’re 
> > > > > waiting for before starting the RC?
> > > > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski 
> > > > > , wrote:
> > > > >
> > > > > That said, if someone can use 8.6.3, what’s stopping them from going 
> > > > > to 8.7 when it’e released?
> > > > >
> > > > >
> > > > > The same things that always stop users from going directly to the
> > > > > latest-and-greatest: fear of instability from new minor-release
> > > > > features, reliance on behavior changed across minor versions, breaking
> > > > > changes on Lucene elements that don't guarantee backcompat (e.g.
> > > > > SOLR-14254), security issues in later versions (new libraries pulled
> > > > > in with vulns), etc. There's lots of reasons a given user might want
> > > > > to stick on 8.6.x rather than 8.7 (in the short/medium term).
> > > > >
> > > > > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> > > > > the worst of the Jetty issue should be mitigated by work on our end -
> > > > > but I think there's a lot of reasons users might not upgrade as far as
> > > > > we'd expect/like.
> > > > >
> > > > >
> > > > > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson 
> > > > 

Re: schema changes and reindexing and user's questions

[Cassandra Targett]

If the old wiki page is old and out of date, just edit it to remove the old 
content and point people who might find the old page to the Ref Guide page. 
There’s no need for a Jira to edit the “old wiki”, just do it IMO. I mean, 
who’s attached to that content? No one is editing a lot of it, that’s for sure.

Every time someone suggests “fixing” the reindexing page, they’ve tended want 
to repeat all the instructions for how to reindex at the top of the page but I 
pretty much disagree with that approach - we need to explain WHY and WHEN 
before HOW. The issue isn’t that the info isn’t available IMO, the issue is 
that people don’t look for it because they have a mental model that schema = 
data dictionary, like a database. I mean, every time someone is surprised that 
changing a field type or properties of a field gave them all sorts of problems, 
it’s because they assumed changing the schema changes the index.

It occurs to me now that what might be helpful is making sure all the docs 
about schema and fields and indexing mention that changes to the schema require 
reindexing, in order to encourage changing the mental model before they ever 
start adding any docs.

This is also I think why people want to get rid of schemaless mode, right? 
Because of this mismatch between expectations and reality.
On Oct 20, 2020, 7:59 AM -0500, Erick Erickson , wrote:
> I found myself yet again trying to explain on the user’s list that if you 
> change your schema, you almost cvertainly have to delete your index and start 
> over. Then a lightbulb went off and I said “Wow! Hasn’t someone written this 
> up somewhere?” The ref guide page “Reindexing.adoc” seems like the right 
> place for this. It already has a section outlining deleting the existing 
> index, I think just a bit of rearranging would help.
>
> I also found: https://cwiki.apache.org/confluence/display/SOLR/HowToReindex, 
> which talks a lot about DataImportHandler. It’s also tagged “old wiki”. 
> Should I raise a JIRA about that given DIH is being moved to a package?
>
> Erick
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: Communicating the future of DIH?

[Cassandra Targett]

Our messages crossed, but I read yours after I sent mine and I think I agree 
with you. I hear “deprecated” and think “it’s going away someday” but I keep 
getting questions from people (even inside Lucidworks) who are panicking like 
it’s gone in 8.6.3 already.

Speaking more generally, though, in some cases, though, we don’t know if it's 
moving - there is no maintainer yet. Until the repo exists and has some 
semblance of organization (a README, etc.), I think it’s very misleading to say 
something will exist somewhere else when it may not. HDFS is an example of 
this. The Deprecations page at 
https://cwiki.apache.org/confluence/display/SOLR/Deprecations says “Community 
package efforts underway”, but as far as I can see that’s just a link to a Jira 
issue where some discussion happened back in July. There is no repo at all yet. 
The plugin may or may not ever arrive.
On Oct 15, 2020, 4:23 PM -0500, David Smiley , wrote:
> Thanks Cassandra.  I read it.  IMO, I think the word "Deprecated" is just too 
> misleading for plugins that are *moving*.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> > On Thu, Oct 15, 2020 at 5:16 PM Cassandra Targett  
> > wrote:
> > > I updated the Ref Guide for 8.7 to include a link to the plugin repo (for 
> > > all plugins which have an established repo, not just DIH), hoping that 
> > > would help answer user questions and spur adoption. That’s just a 
> > > super-minor thing, but it’s something.
> > >
> > > If Rohit doesn’t have time to be a maintainer now and no one else wants 
> > > to be, would a separate GitHub org help that? I understand the motivation 
> > > for sharing the burden…I guess you’re thinking that single org would 
> > > allow people to be maintainers on multiple plugins?
> > >
> > > Draft for 8.7 Guide is here if interested to see what I did: 
> > > https://nightlies.apache.org/Lucene/Solr-reference-guide-8.x/uploading-structured-data-store-data-with-the-data-import-handler.html
> > > On Oct 15, 2020, 3:52 PM -0500, Jan Høydahl , 
> > > wrote:
> > > > Some of those issues are opened by me, not beause I plan to be a DIH 
> > > > maintainer myself, but I was hoping that Rohit had some real interest 
> > > > in forming a comunity.
> > > > Turns out that the plugin is as good as dead on arrival, which is 
> > > > really disappointing.
> > > >
> > > > We as the donator could perhaps help by sending an email, with a 
> > > > reminder that DIH is being deprecated and that the new plugin really 
> > > > needs more maintainers.
> > > > That’s why I filed 
> > > > https://github.com/rohitbemax/dataimporthandler/issues/12, else people 
> > > > arriving to the page would not even know how to contribute or become a 
> > > > committer.
> > > > I could whip up a PR for the README inviting contributors, but I’m 
> > > > honestly not so sure that newcomers would feel welcome, as their 
> > > > contributions would likely attract no attention :(
> > > >
> > > > So I wonder if instead someone (Ishan?) should setup a new GitHub 
> > > > organization, migrate the project there, and add Rohit and others as 
> > > > maintainers. That lifts the burden off one man's shoulders.
> > > >
> > > > Jan
> > > >
> > > > > a15. okt. 2020 kl. 21:40 skrev Marcus Eagan :
> > > > >
> > > > > There’s always issues opened in every product that aren’t being 
> > > > > closed. Everyone who knows it or cares about it should be pitching in.
> > > > >
> > > > > Marcus
> > > > >
> > > > > > On Thu, Oct 15, 2020 at 12:21 Eric Pugh 
> > > > > >  wrote:
> > > > > > > I noticed that we’re getting tickets like SOLR-14938 opened that 
> > > > > > > are all about the future of DIH.  I know some of my own clients 
> > > > > > > are asking about it as well.   I suspect we will get more and 
> > > > > > > more of these!
> > > > > > >
> > > > > > > I wonder if there are any ideas/suggestions on how to better 
> > > > > > > communicate that DIH isn’t going away, and indeed, it’s moving to 
> > > > > > > a better place (I hope!).   Do we want to add to the UI a message 
> > > > > > > about “join the new community at 
> > > > > > > https://github.com/rohitbemax/dataimpo

Re: Communicating the future of DIH?

[Cassandra Targett]

I updated the Ref Guide for 8.7 to include a link to the plugin repo (for all 
plugins which have an established repo, not just DIH), hoping that would help 
answer user questions and spur adoption. That’s just a super-minor thing, but 
it’s something.

If Rohit doesn’t have time to be a maintainer now and no one else wants to be, 
would a separate GitHub org help that? I understand the motivation for sharing 
the burden…I guess you’re thinking that single org would allow people to be 
maintainers on multiple plugins?

Draft for 8.7 Guide is here if interested to see what I did: 
https://nightlies.apache.org/Lucene/Solr-reference-guide-8.x/uploading-structured-data-store-data-with-the-data-import-handler.html
On Oct 15, 2020, 3:52 PM -0500, Jan Høydahl , wrote:
> Some of those issues are opened by me, not beause I plan to be a DIH 
> maintainer myself, but I was hoping that Rohit had some real interest in 
> forming a comunity.
> Turns out that the plugin is as good as dead on arrival, which is really 
> disappointing.
>
> We as the donator could perhaps help by sending an email, with a reminder 
> that DIH is being deprecated and that the new plugin really needs more 
> maintainers.
> That’s why I filed https://github.com/rohitbemax/dataimporthandler/issues/12, 
> else people arriving to the page would not even know how to contribute or 
> become a committer.
> I could whip up a PR for the README inviting contributors, but I’m honestly 
> not so sure that newcomers would feel welcome, as their contributions would 
> likely attract no attention :(
>
> So I wonder if instead someone (Ishan?) should setup a new GitHub 
> organization, migrate the project there, and add Rohit and others as 
> maintainers. That lifts the burden off one man's shoulders.
>
> Jan
>
> > a15. okt. 2020 kl. 21:40 skrev Marcus Eagan :
> >
> > There’s always issues opened in every product that aren’t being closed. 
> > Everyone who knows it or cares about it should be pitching in.
> >
> > Marcus
> >
> > > On Thu, Oct 15, 2020 at 12:21 Eric Pugh  
> > > wrote:
> > > > I noticed that we’re getting tickets like SOLR-14938 opened that are 
> > > > all about the future of DIH.  I know some of my own clients are asking 
> > > > about it as well.   I suspect we will get more and more of these!
> > > >
> > > > I wonder if there are any ideas/suggestions on how to better 
> > > > communicate that DIH isn’t going away, and indeed, it’s moving to a 
> > > > better place (I hope!).   Do we want to add to the UI a message about 
> > > > “join the new community at 
> > > > https://github.com/rohitbemax/dataimporthandler”?
> > > >
> > > > Having said that, I see issues opening at 
> > > > https://github.com/rohitbemax/dataimporthandler and not being closed, 
> > > > so I do have some concerns that a supportive community may not actually 
> > > > be forming.
> > > >
> > > >
> > > > Eric
> > > >
> > > > ___
> > > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 
> > > > | http://www.opensourceconnections.com | My Free/Busy
> > > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> > > > This e-mail and all contents, including attachments, is considered to 
> > > > be Company Confidential unless explicitly stated otherwise, regardless 
> > > > of whether attachments are marked as such.
> > > >
> > --
> > Marcus Eagan
> >
>

Re: [JENKINS] Lucene » Solr-reference-guide-8.x - Build # 83 - Failure!

[Cassandra Targett]

Oops, I did some bad conflict resolution on a doc. Fixing.
On Oct 9, 2020, 12:10 PM -0500, Apache Jenkins Server 
, wrote:
> Build: 
> https://ci-builds.apache.org/job/Lucene/job/Solr-reference-guide-8.x/83/
>
> Log:
> Started by an SCM change
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> Building remotely on websites1 (git-websites svn-websites) in workspace 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x
> No credentials specified
> > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
> > git config remote.origin.url 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
> Cleaning workspace
> > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
> > git reset --hard # timeout=10
> > git clean -fdx # timeout=10
> Fetching upstream changes from 
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> > git --version # timeout=10
> > git fetch --tags --progress -- 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git 
> > +refs/heads/*:refs/remotes/origin/* # timeout=10
> > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
> Checking out Revision c14eb1339840ec137d58f9e76dc07f344d6d1d77 
> (refs/remotes/origin/branch_8x)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f c14eb1339840ec137d58f9e76dc07f344d6d1d77 # timeout=10
> Commit message: "Ref Guide: update for 8.7 upgrade notes"
> > git rev-list --no-walk 4d22711ae2c947b0eaa5410f02bca539ed915c6a # timeout=10
> No emails were triggered.
> [solr-ref-guide] $ /home/jenkins/tools/ant/apache-ant-1.8.4/bin/ant -file 
> build.xml build-site
> Buildfile: 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/solr-ref-guide/build.xml
>
> build-init:
> [mkdir] Created dir: 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/content
> [echo] Copying all non template files from src ...
> [copy] Copying 468 files to 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/content
> [echo] Copy (w/prop replacement) any template files from src...
> [copy] Copying 1 file to 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/content
>
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
>
> -ivy-fail-disallowed-ivy-version:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 :: 
> http://ant.apache.org/ivy/ ::
> [ivy:configure] :: loading settings :: file = 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/lucene/top-level-ivy-settings.xml
>
> resolve:
>
> build-tools-jar:
> [mkdir] Created dir: 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/classes
> [javac] Compiling 3 source files to 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/classes
> [copy] Copying 1 file to 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/classes
> [jar] Building jar: 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/solr-ref-guide-tools.jar
>
> build-nav-data-files:
> [java] Building up tree of all known pages
> [java] Looping over pages to build nav data
> [java] Creating 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/content/_data/scrollnav.json
> [java] Creating 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/content/_data/sidebar.json
>
> -build-site:
> [echo] Running Jekyll...
> [exec] Logging at level: debug
> [exec] �[31m Deprecation: The 'gems' configuration option has been renamed to 
> 'plugins'. Please update your config file accordingly.�[0m
> [exec] Configuration file: 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/content/_config.yml
> [exec] Requiring: jekyll-asciidoc
> [exec] Requiring: kramdown
> [exec] Source: 
> /home/jenkins/712657a4/workspace/Lucene/Solr-reference-guide-8.x/solr/build/solr-ref-guide/content
> [exec] Destination: ../html-site
> [exec] Incremental build: disabled. Enable with --incremental
> [exec] Generating...
> [exec] Generating: Jekyll::AsciiDoc::Integrator finished in 0.241740909 
> seconds.
> [exec] Rendering: a-quick-overview.adoc
> [exec] Pre-Render Hooks: a-quick-overview.adoc
> [exec] Rendering Markup: a-quick-overview.adoc
> [exec] Rendering Layout: a-quick-overview.adoc
> [exec] Rendering: about-filters.adoc
> [exec] Pre-Render Hooks: about-filters.adoc
> [exec] Rendering Markup: about-filters.adoc
> [exec] Rendering Layout: about-filters.adoc
> [exec] Rendering: about-this-guide.adoc
> [exec] Pre-Render Hooks: about-this-guide.adoc
> [exec] 

Re: 8.6.3 Release

[Cassandra Targett]

We discussed this before and agreed that could be removed. I made a patch to 
remove it but my editor always removes trailing whitespace and Jan doesn’t want 
that for some reason and I haven’t had time to go back to it. See 
https://issues.apache.org/jira/browse/LUCENE-9434.
On Oct 9, 2020, 11:09 AM -0500, Jason Gerlowski , wrote:
> Small correction: I see now some pages for 8.4 and 8.6 in a different
> section of the wiki tree. But the overall point still stands I think
> - this hasn't been done consistently and it doesn't seem like that's
> caused any problems (as the pages are all stubs anyways).
>
> On Fri, Oct 9, 2020 at 12:05 PM Jason Gerlowski  wrote:
> >
> > The traditional (non-docker) part of the release should now be wrapped
> > up. Thanks everyone for the help and answering my questions here and
> > in Slack. One final question:
> >
> > The final releaseWizard.py step instructs:
> >
> > "The Solr WIKI has a page for every version which is often linked to
> > from WIKI pages to indicate differences between versions, example:
> > http://wiki.apache.org/solr/Solr4.3. Do the following: Update the page
> > for the released version with release date and link to release
> > statement. Create a new placeholder page for the "next" version, if it
> > does not exist"
> >
> > But looking at our wiki, the latest of these pages is 8.2
> > (https://cwiki.apache.org/confluence/display/SOLR/Solr8.2). I've
> > created the pages as instructed for now. But if we're not following
> > this step regularly and it hasn't caused any issues maybe we should
> > remove it from the release process altogether?
> >
> > Jason
> >
> > On Thu, Oct 8, 2020 at 5:16 PM David Smiley  wrote:
> > >
> > > The way GitHub works for contributors is that you are expected to fork a 
> > > repo and then push to your fork. At that point when you go to the PR 
> > > area, you'll see a convenient yellow dialog to create a PR based on your 
> > > pushed branch.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Thu, Oct 8, 2020 at 10:20 AM Chris Hostetter 
> > >  wrote:
> > > >
> > > >
> > > > FWIW: I followed the docs to update the Dockerfiles + TAGS for 8.6.3, 
> > > > and
> > > > run tests; but since it's in a distinct github repo I don't think i can
> > > > push to it?
> > > >
> > > > so i creaed a GH issue w/patch...
> > > >
> > > > https://github.com/docker-solr/docker-solr/issues/349
> > > >
> > > >
> > > >
> > > > : Date: Tue, 6 Oct 2020 11:33:15 -0400
> > > > : From: Houston Putman 
> > > > : Reply-To: dev@lucene.apache.org
> > > > : To: Solr/Lucene Dev 
> > > > : Subject: Re: 8.6.3 Release
> > > > :
> > > > : That is correct. 8.x docker builds have not been affected in any way.
> > > > :
> > > > : On Tue, Oct 6, 2020 at 11:30 AM Cassandra Targett 
> > > > 
> > > > : wrote:
> > > > :
> > > > : > I wanted to ask now that the 8.6.3 vote is underway - for the 
> > > > docker-solr
> > > > : > image, are the update instructions in the docker-solr repo still 
> > > > the same
> > > > : > for 8.x even though the build process has been moved to the main 
> > > > project
> > > > : > for 9.0? Meaning, to release the 8.6.3 image there’s no change from 
> > > > before,
> > > > : > right?
> > > > : >
> > > > : > I’m asking specifically about these instructions:
> > > > : >
> > > > : > https://github.com/docker-solr/docker-solr/blob/master/update.md
> > > > : > On Oct 1, 2020, 9:28 AM -0500, Jason Gerlowski 
> > > > ,
> > > > : > wrote:
> > > > : >
> > > > : > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> > > > : > someone please sanity check the summaries there when they get a
> > > > : > chance? Would appreciate the review.
> > > > : >
> > > > : > 8.6.3 is a bit interesting in that Lucene has no changes in this
> > > > : > bugfix release. As a result I had to omit the standard phrase in the
> > > > : > Solr release notes about there being additional changes at the 
> > > > Lucene
> > > > : > le

Re: 8.6.3 Release

[Cassandra Targett]

I wanted to ask now that the 8.6.3 vote is underway - for the docker-solr 
image, are the update instructions in the docker-solr repo still the same for 
8.x even though the build process has been moved to the main project for 9.0? 
Meaning, to release the 8.6.3 image there’s no change from before, right?

I’m asking specifically about these instructions:

https://github.com/docker-solr/docker-solr/blob/master/update.md
On Oct 1, 2020, 9:28 AM -0500, Jason Gerlowski , wrote:
> I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> someone please sanity check the summaries there when they get a
> chance? Would appreciate the review.
>
> 8.6.3 is a bit interesting in that Lucene has no changes in this
> bugfix release. As a result I had to omit the standard phrase in the
> Solr release notes about there being additional changes at the Lucene
> level, and change some of the wording in the Lucene announcement to
> indicate the lack of changes. So that's something to pay particular
> attention to, if someone can check my wording there.
>
> [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> [2] https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>
> On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
> wrote:
> >
> > The only one that was previously mentioned as a blocker was
> > SOLR-14835, but from the comments on the ticket it looks like it ended
> > up being purely a cosmetic issue. Andrzej left a comment there
> > suggesting that we "address" this with documentation for 8.6.3 but
> > otherwise leave it as-is.
> >
> > So it looks like we're unblocked on starting the release process.
> > Will begin the preliminary steps this afternoon.
> >
> > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett  
> > wrote:
> > >
> > > It looks to me like everything for 8.6.3 is resolved now 
> > > (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it 
> > > seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a 
> > > Jetty upgrade less compelling to try.
> > >
> > > Are there any other issues not currently marked for 8.6.3 we’re waiting 
> > > for before starting the RC?
> > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski , 
> > > wrote:
> > >
> > > That said, if someone can use 8.6.3, what’s stopping them from going to 
> > > 8.7 when it’e released?
> > >
> > >
> > > The same things that always stop users from going directly to the
> > > latest-and-greatest: fear of instability from new minor-release
> > > features, reliance on behavior changed across minor versions, breaking
> > > changes on Lucene elements that don't guarantee backcompat (e.g.
> > > SOLR-14254), security issues in later versions (new libraries pulled
> > > in with vulns), etc. There's lots of reasons a given user might want
> > > to stick on 8.6.x rather than 8.7 (in the short/medium term).
> > >
> > > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> > > the worst of the Jetty issue should be mitigated by work on our end -
> > > but I think there's a lot of reasons users might not upgrade as far as
> > > we'd expect/like.
> > >
> > >
> > > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson  
> > > wrote:
> > >
> > >
> > > For me, there’s a sharp distinction between changing a dependency in a 
> > > point release just because there’s a new version, and changing the 
> > > dependency because there’s a bug in it. That said, if someone can use 
> > > 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would 
> > > it make more sense to do the upgrades for 8.7 and get that out the door 
> > > rather than backport?
> > >
> > > FWIW,
> > > Erick
> > >
> > > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski  
> > > wrote:
> > >
> > > Hey all,
> > >
> > > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
> > > SOLR-14898. These tickets (while bad bugs in their own right) are
> > > especially necessary because they work around a Jetty buffer-reuse bug
> > > (see SOLR-14896) that causes sporadic request failures once triggered.
> > >
> > > So that brings the list of 8.6.3 blockers up to: SOLR-14850,
> > > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
> > > work on SOLR-14768!)
> > >
> > > Additionally, should we also consider a Jetty upgrade for 8.6.3 in
>

Re: 8.6.3 Release

[Cassandra Targett]

It looks to me like everything for 8.6.3 is resolved now 
(https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it seems 
from comments in SOLR-14897 and SOLR-14898 that those fixes make a Jetty 
upgrade less compelling to try.

Are there any other issues not currently marked for 8.6.3 we’re waiting for 
before starting the RC?
On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski , wrote:
> > That said, if someone can use 8.6.3, what’s stopping them from going to 8.7 
> > when it’e released?
>
> The same things that always stop users from going directly to the
> latest-and-greatest: fear of instability from new minor-release
> features, reliance on behavior changed across minor versions, breaking
> changes on Lucene elements that don't guarantee backcompat (e.g.
> SOLR-14254), security issues in later versions (new libraries pulled
> in with vulns), etc. There's lots of reasons a given user might want
> to stick on 8.6.x rather than 8.7 (in the short/medium term).
>
> I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> the worst of the Jetty issue should be mitigated by work on our end -
> but I think there's a lot of reasons users might not upgrade as far as
> we'd expect/like.
>
>
> On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson  
> wrote:
> >
> > For me, there’s a sharp distinction between changing a dependency in a 
> > point release just because there’s a new version, and changing the 
> > dependency because there’s a bug in it. That said, if someone can use 
> > 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would it 
> > make more sense to do the upgrades for 8.7 and get that out the door rather 
> > than backport?
> >
> > FWIW,
> > Erick
> >
> > > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski  
> > > wrote:
> > >
> > > Hey all,
> > >
> > > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
> > > SOLR-14898. These tickets (while bad bugs in their own right) are
> > > especially necessary because they work around a Jetty buffer-reuse bug
> > > (see SOLR-14896) that causes sporadic request failures once triggered.
> > >
> > > So that brings the list of 8.6.3 blockers up to: SOLR-14850,
> > > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
> > > work on SOLR-14768!)
> > >
> > > Additionally, should we also consider a Jetty upgrade for 8.6.3 in
> > > light of the issue mentioned above? I know it's atypical for bug-fix
> > > releases to change deps, but here the bug is serious and tied directly
> > > to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the
> > > Jetty bug is likely still a problem for users making requests that
> > > match a specific (albeit rare) profile. Anyone have thoughts?
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Fri, Sep 25, 2020 at 12:28 AM Houston Putman  
> > > wrote:
> > > >
> > > > If I recall correctly, thats a step in the release wizard.
> > > >
> > > > After checking, I think this fits the bill:
> > > > https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435
> > > >
> > > > - Houston
> > > >
> > > > On Fri, Sep 25, 2020 at 12:06 AM David Smiley  
> > > > wrote:
> > > > >
> > > > > When moving changes from 8.7 to 8.6.3, must we (the mover of an 
> > > > > individual change) move the CHANGES.txt entry on all branches -- 
> > > > > master, branch_8x, branch_8_6? I expect the release branch but am 
> > > > > unsure of the other two. In the past I have but it's annoying. Does 
> > > > > the RM sync CHANGES.txt on the other branches in one go? If not, I 
> > > > > think it'd make sense for that to happen.
> > > > >
> > > > > ~ David Smiley
> > > > > Apache Lucene/Solr Search Developer
> > > > > http://www.linkedin.com/in/davidwsmiley
> > > > >
> > > > >
> > > > > On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma  wrote:
> > > > > >
> > > > > > I will push the 8.7 release by a week to give Jason enough headroom 
> > > > > > to
> > > > > >
> > > > > >
> > > > > > do the 8.6.3 release.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Jason, let me know if you need me to assist on the 8.6.3 release.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 24, 2020 at 3:23 PM Jason Gerlowski 
> > > > > >  wrote:
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > > OK, in that case I'll try my best to keep the 8.6.3 process moving
> > > > > >
> > > > > >
> > > > > > > then, so Atri can stick as close to his proposed schedule as 
> > > > > > > possible.
> > > > > >
> > > > > >
> > > > > > > My apologies - I didn't realize I'd be putting the brakes on 8.7 
> > > > > > > by
> > > > > >
> > > > > >
> > > > > > > proposing a bug-fix release. But the reasons make sense given what
> > > > > >
> > > > > >
> > > > > > > others mentioned above.
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > > > As branch_8_6 should be pretty stable by now I wonder if we 
> > > > > 

Re: 8.7 Release

[Cassandra Targett]

Atri,

Just so I understand your plans, when you say you are planning to start the 
process at the end of this month, you mean you intend to create the branch 
around Oct 1? No pressure, I ask only because Ishan’s original mail mentioned 
cutting the branch this week and I just wanted to have a clearer sense of your 
timeline.

Thanks,
Cassandra
On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:
> I was planning to start the process end of this month.
>
> > On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
> > > Unless it somehow got lost in a spam filter somewhere, I don't think we 
> > > have set a target date for the release yet? (roadmap says autumn 2020 
> > > which technically doesn't begin until the solstice on the 21st :) )
> > >
> > > Hoping that I might still get the Advanced Query parser in first, but 
> > > that's a much bigger prospect than these two tickets.
> > >
> > > -Gus
> > >
> > > > On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher  
> > > > wrote:
> > > > > Unless there are objections, I'm gonna get 
> > > > > https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
> > > > >
> > > > >   Erik
> > > > >
> > > > >
> > > > > > On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ 
> > > > > > LONDON)  wrote:
> > > > > >
> > > > > > With a view towards including it in the release, I'd appreciate 
> > > > > > input on the
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/SOLR-14828
> > > > > >
> > > > > > solrj logging tweak if anyone has a moment?
> > > > > >
> > > > > > Thanks,
> > > > > > Christine
> > > > > >
> > > > > > From: dev@lucene.apache.org At: 08/20/20 22:48:39
> > > > > > To: dev@lucene.apache.org
> > > > > > Subject: Re: 8.7 Release
> > > > > >
> > > > > > > Also, we should try to respect the stuff we have put on the 
> > > > > > > roadmap (Which includes me getting a patch up for SIP-9 much 
> > > > > > > sooner rather than even a little later!)
> > > > > > >
> > > > > > > > On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand 
> > > > > > > >  wrote:
> > > > > > > > > Thanks for the explanation Ishan.
> > > > > > > > >
> > > > > > > > > > On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya 
> > > > > > > > > >  wrote:
> > > > > > > > > > > Hi Adrien,
> > > > > > > > > > > I think I am mainly concerned about getting the 
> > > > > > > > > > > configuration and modularity of this right before we 
> > > > > > > > > > > release: https://issues.apache.org/jira/browse/SOLR-14588.
> > > > > > > > > > > If we aren't able to resolve it, we should revert that 
> > > > > > > > > > > feature.
> > > > > > > > > > >
> > > > > > > > > > > There may be some other performance issues that may have 
> > > > > > > > > > > been marked as blockers just to infuse a sense of urgency 
> > > > > > > > > > > among those that need to fix it. But, I wouldn't consider 
> > > > > > > > > > > them something that actually holds up a release.
> > > > > > > > > > > Regards,
> > > > > > > > > > > Ishan
> > > > > > > > > > >
> > > > > > > > > > > > On Fri, Aug 21, 2020 at 1:56 AM Adrien Grand 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > Noble, I'm curious what blockers you have in mind. I 
> > > > > > > > > > > > > just checked JIRA, and while I see a number of 9.0 
> > > > > > > > > > > > > blockers, I'm not counting many 8.7 blockers?
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Aug 20, 2020 at 11:13 AM Noble Paul 
> > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > There are a lot of blockers for 8.7. It's good to 
> > > > > > > > > > > > > > > plan in advance
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Aug 20, 2020 at 7:11 PM Ishan 
> > > > > > > > > > > > > > > Chattopadhyaya
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi devs,
> > > > > > > > > > > > > > > > A lot of changes are now in 8.7 or in-flight. 
> > > > > > > > > > > > > > > > I'd like to volunteer for a 8.7 release in 
> > > > > > > > > > > > > > > > around a month from now (cutting the release 
> > > > > > > > > > > > > > > > branch around 20 September) and RC shortly 
> > > > > > > > > > > > > > > > after. I feel this timeline will give all of us 
> > > > > > > > > > > > > > > > ample time to wrap up the release blockers, 
> > > > > > > > > > > > > > > > other changes and improvements.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does someone have any thoughts, concerns or 
> > > > > > > > > > > > > > > > objections?
> > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > Ishan
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > -
> > > > > > > > > > > > > > > Noble Paul
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -
> > > > 

Re: Remove section for 9.0 solr/CHANGES

[Cassandra Targett]

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 features in fact disappear, which makes the need for such a 
page somewhat transient. The fact of their deprecation is mentioned in the 
Upgrade Notes for the release when they are deprecated, and a notice is 
prominent on each page related to the feature. With this in mind, I’m not sure 
I see the need for a separate page and would have several questions: Would we 
have a separate page “Deprecated Features" in 9.0 and then remove it in 9.1? Do 
we carry around a page only relevant for 9.0 through each version until we 
someday realize it’s out-of-date and remove it? Does this page duplicate what's 
in the “Deprecations” Wiki page, or does it augment that information in some 
other way? Since there would be 2 pages for deprecations, who's maintaining 
both of them?
On Sep 2, 2020, 12:16 PM -0500, Houston Putman , wrote:
> 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 goal of deprecating these features, then 
> dive into the plugin/alternatives for each feature that is affected.
>
> - Houston
>
> > On Wed, Sep 2, 2020 at 12:51 PM Christine Poerschke (BLOOMBERG/ LONDON) 
> >  wrote:
> > > 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:19
> > > To: dev@lucene.apache.org
> > > Subject: Re: Remove section for 9.0 solr/CHANGES
> > >
> > > > Maybe even distinguish between features that do have a replacement ( 
> > > > via a plugin ) and those that don't
> > > >
> > > > > On Sun, Aug 30, 2020 at 1:49 PM Varun Thacker  
> > > > > wrote:
> > > > > > Currently when looking at the "Other Changes" section in the 
> > > > > > CHANGES entry for 9.0 most of the items are removal of features
> > > > > >
> > > > > > For 9.0 should we have a special "Feature Removal" section within 
> > > > > > the CHANGES file ?
> > > > > >
> > > > > > We could add Autoscaling / CDCR / DIH / ANT etc to that secttion
> > >

Re: Do we actually merge the GitHub pull requests?

[Cassandra Targett]

If you don’t see an option to squash merge in a few hours, I’d suggest talking 
to Infra team - they’re on the asf-slack at #infra.

Cassandra
On Aug 28, 2020, 1:56 PM -0500, Alexandre Rafalovitch , 
wrote:
> I did some linking before, but not the gitbox that I remember. Did it
> now and it says, I have access to:
> * lucene-site
> * lucene-solr
>
> So hopefully but the time I am ready to merge, I can. If not, I'll be back 
> here.
>
> Thank you,
> Alex.
>
> On Fri, 28 Aug 2020 at 14:15, Cassandra Targett  wrote:
> >
> > You do have to link your GitHub and Apache identities. You need to have 2FA 
> > enabled on your GH account.
> >
> > Add your GH ID to your ASF LDAP profile at id.apache.org. It can take a 
> > couple hours for you to be added to the Apache org in GitHub.
> >
> > I think that’s all it takes, but you can go here to check the status and 
> > what repos you have access to: https://gitbox.apache.org/setup/ (or, I 
> > might have it backwards, and you have to request it no matter what. Either 
> > way, if it doesn’t work by adding to your LDAP profile, you can use the 
> > gitbox link to request it to be done).
> >
> > Cassandra
> > On Aug 28, 2020, 12:48 PM -0500, Uwe Schindler , wrote:
> >
> > You need to squash merge, real merging is not allowed on GitHub.
> >
> > With git client it works of course, but we want external pull request not 
> > pollute our history.
> >
> > Uwe
> >
> > Am August 28, 2020 5:45:27 PM UTC schrieb Alexandre Rafalovitch 
> > :
> > >
> > > I am working on finalizing
> > > https://github.com/apache/lucene-solr/pull/1794 (DIH removal) and when
> > > I looked at it (before conflicts), it did not allow me to merge.
> > >
> > > It said instead:
> > > "Only those with write access to this repository can merge pull requests."
> > >
> > > Did I have to do some extra linking of my personal and apache
> > > identities? I am already an apache org member and I am pretty sure
> > > (not 100%) that I pushed directly into GitHub repo before. But now
> > > when I am doing it via PR, it seems different.
> > >
> > > Can anybody else merge and I can't? Or we just don't do merges?
> > >
> > > Regards,
> > > Alex.
> > >
> > > 
> > >
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> > --
> > Uwe Schindler
> > Achterdiek 19, 28357 Bremen
> > https://www.thetaphi.de

Re: Do we actually merge the GitHub pull requests?

[Cassandra Targett]

You do have to link your GitHub and Apache identities. You need to have 2FA 
enabled on your GH account.

Add your GH ID to your ASF LDAP profile at id.apache.org. It can take a couple 
hours for you to be added to the Apache org in GitHub.

I think that’s all it takes, but you can go here to check the status and what 
repos you have access to: https://gitbox.apache.org/setup/ (or, I might have it 
backwards, and you have to request it no matter what. Either way, if it doesn’t 
work by adding to your LDAP profile, you can use the gitbox link to request it 
to be done).

Cassandra
On Aug 28, 2020, 12:48 PM -0500, Uwe Schindler , wrote:
> You need to squash merge, real merging is not allowed on GitHub.
>
> With git client it works of course, but we want external pull request not 
> pollute our history.
>
> Uwe
>
> > Am August 28, 2020 5:45:27 PM UTC schrieb Alexandre Rafalovitch 
> > :
> > > I am working on finalizing
> > > https://github.com/apache/lucene-solr/pull/1794 (DIH removal) and when
> > > I looked at it (before conflicts), it did not allow me to merge.
> > >
> > > It said instead:
> > > "Only those with write access to this repository can merge pull requests."
> > >
> > > Did I have to do some extra linking of my personal and apache
> > > identities? I am already an apache org member and I am pretty sure
> > > (not 100%) that I pushed directly into GitHub repo before. But now
> > > when I am doing it via PR, it seems different.
> > >
> > > Can anybody else merge and I can't? Or we just don't do merges?
> > >
> > > Regards,
> > >   Alex.
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de

Re: Migrating to Cloudbees

[Cassandra Targett]

Follow-up on this - we fixed the Solr Ref Guide builds last week, but there was 
an outstanding issue which was the Content Security Policy on Cloudbees is too 
stringent to display the Ref Guide’s CSS and JS. It blocked all the content 
basically, rendering them unreadable.

Infra helped us straighten it out by setting up the ability for us to push the 
artifacts of Ref Guide builds to a new server they’ve recently set up to host 
nightly builds. I’ve updated all the Ref Guide jobs to do that and fixed their 
descriptions to point to the new locations. You can find them at 
https://nightlies.apache.org/Lucene/.

The Javadocs for both Lucene and Solr also suffer from the same limited CSP, 
but the Javadocs seem to be able to mostly recover from it. It is possible to 
push them to the nightlies server for the full JS-enabled experience if we 
choose.

Infra is also quite open (enthusiastic?) for people to use this server, so if 
there is any interest in pushing other build artifacts out to it as a regular 
place to get pre-release builds, we’re welcome to do so. I can help, or you can 
look at one of the Ref Guide jobs for an example.

Cassandra
On Aug 7, 2020, 12:17 PM -0500, Ishan Chattopadhyaya 
, wrote:
> Thanks for your work, Uwe. I would love to run a public Jenkins server soon 
> (maybe be September), would like to try out your scripts :-)
>
> > On Fri, Aug 7, 2020 at 10:12 PM David Smiley  wrote:
> > > Sweet!  Thanks Uwe!
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > > On Thu, Aug 6, 2020 at 5:52 PM Uwe Schindler  wrote:
> > > > > Thanks Erick!
> > > > >
> > > > > I hope the remaining issues sort out quite soon.
> > > > >
> > > > > For the release managers: As I did a more scripted, automatic 
> > > > > migration using the Jenkins REST API (otherwise the 50 jobs we have 
> > > > > would have been a desaster to migrate), I already have a plan to 
> > > > > reuse that script to allow the release manager to create clones of 
> > > > > all "master" jobs, preconfigured for the release branch. All you need 
> > > > > is a Lucene PMC status and a Jenkins API Token and then you will be 
> > > > > able to start a script who creates all release branch jobs in a few 
> > > > > seconds 
> > > > >
> > > > > Uwe
> > > > >
> > > > > -
> > > > > Uwe Schindler
> > > > > Achterdiek 19, D-28357 Bremen
> > > > > https://www.thetaphi.de
> > > > > eMail: u...@thetaphi.de
> > > > >
> > > > > > -Original Message-
> > > > > > From: Erick Erickson 
> > > > > > Sent: Thursday, August 6, 2020 11:39 PM
> > > > > > To: dev@lucene.apache.org
> > > > > > Subject: Migrating to Cloudbees
> > > > > >
> > > > > > If nobody has expressed their _extreme_ gratitude to Uwe, infra 
> > > > > > (and helpers?)
> > > > > > for the migration, I hereby rectify that!!
> > > > > > -
> > > > > > 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: Naming of non-SolrCloud clusters in the Ref Guide

[Cassandra Targett]

OK, fair point about self-managed. But I object to "leaving it" as Legacy, as 
I've previously explained (I put that in quotes because it’s not always called 
that at all - it has at least 3 names right now).

The reality is someone can come up with an objection to every single 
possibility. Someday we have to live with something that’s good enough and move 
forward, or we’ll end up just living with the total mash of things we have 
today. Which maybe is fine with everyone.

I’ve tried to put real mental work into thinking about a good name, and have 
tried to compromise based on feedback. At this point, though, unless someone 
else comes up with something I’m likely done here. We’ll just “leave it” all as 
it is now.

Cassandra
On Aug 11, 2020, 9:11 AM -0500, Ishan Chattopadhyaya 
, wrote:
> I object to "self managed". It gives the impression that Solr manages itself, 
> whereas it is the other way around: users need to manage the standalone mode 
> with lots of manual effort, as opposed to SolrCloud which is in spirit self 
> managed (solr manages itself using zk).
>
> I'm +1 with Legacy replication and SolrCloud replication for now. Later, we 
> can get rid of "SolrCloud" and call it something else. Also, once SolrCloud 
> is stable enough, we can get rid of legacy mode altogether. We can discuss 
> that elsewhere.
>
> > On Tue, 11 Aug, 2020, 7:16 pm Cassandra Targett,  
> > wrote:
> > > I don’t feel there is a consensus for me to move forward confidently, but 
> > > the docs need to be fixed before 8.7. I’ve thought about Ilan’s 
> > > suggestion, and like calling the non-SolrCloud cluster “self-managed”. It 
> > > avoids the currently awkward phrasing and any misinterpretation of my 
> > > original suggestion with clumsiness as Gus pointed out. Can everyone live 
> > > with that?
> > >
> > > If so, that leaves what we might eventually call SolrCloud is the 
> > > remaining sticking point. It’s not a problem that needs to be solved 
> > > today as the term isn’t going anywhere yet since there aren’t any patches 
> > > or PRs to change it at a code level.
> > >
> > > Barring further objections, then, I think I will go ahead with mostly 
> > > leaving “SolrCloud” as it is, and replacing/modifying “Legacy Scaling”, 
> > > “leader/follower mode”, some cases of “Standalone mode”, and similar 
> > > constructions with “Self-Managed Mode” or “Self-Managed Cluster”, etc., 
> > > as appropriate.
> > >
> > > Cassandra
> > > On Aug 7, 2020, 9:05 AM -0500, Cassandra Targett , 
> > > wrote:
> > > > The suggestion to use “managed” and maybe “self-managed” is an 
> > > > interesting one. Do you think it’s possible some might confuse that 
> > > > with the other ways we use managed - like the “managed-schema”, and 
> > > > “managed resources” (synonyms and stop words)? Neither of those are 
> > > > cluster-specific, and I wonder if the overlap in terminology would 
> > > > cause them to be conflated.
> > > >
> > > > Cassandra
> > > > On Aug 6, 2020, 10:51 AM -0500, Ilan Ginzburg , 
> > > > wrote:
> > > > > Both "legacy" and "SolrCloud" clusters are search server clusters. 
> > > > > Seen from far enough, they look the same.
> > > > >
> > > > > In "legacy" the management code is elsewhere (developed by the client 
> > > > > operating the cluster, running on other machines using a diferent 
> > > > > logic and potentially another DB than Zookeeper) whereas in 
> > > > > "SolrCloud" the management code is embedded in the search server(s) 
> > > > > code and it happens that (currently) this code relies on Zookeeper.
> > > > >
> > > > > I see SolrCloud as a "managed cluster" vs. legacy that would be "Self 
> > > > > managed" by the client, or "U manage" (non managed when looking at it 
> > > > > from the Solr codebase perspective).
> > > > >
> > > > > Same idea as coordinated vs uncoordinated basically. I don't know why 
> > > > > but I prefer "managed".
> > > > >
> > > > > Ilan
> > > > >
> > > > > > On Thu, Aug 6, 2020 at 5:49 PM Cassandra Targett 
> > > > > >  wrote:
> > > > > > > On Aug 6, 2020, 10:22 AM -0500, Gus Heck , 
> > > > > > > wrote:
> > > > > > > > WRT the n

Re: Naming of non-SolrCloud clusters in the Ref Guide

[Cassandra Targett]

I don’t feel there is a consensus for me to move forward confidently, but the 
docs need to be fixed before 8.7. I’ve thought about Ilan’s suggestion, and 
like calling the non-SolrCloud cluster “self-managed”. It avoids the currently 
awkward phrasing and any misinterpretation of my original suggestion with 
clumsiness as Gus pointed out. Can everyone live with that?

If so, that leaves what we might eventually call SolrCloud is the remaining 
sticking point. It’s not a problem that needs to be solved today as the term 
isn’t going anywhere yet since there aren’t any patches or PRs to change it at 
a code level.

Barring further objections, then, I think I will go ahead with mostly leaving 
“SolrCloud” as it is, and replacing/modifying “Legacy Scaling”, 
“leader/follower mode”, some cases of “Standalone mode”, and similar 
constructions with “Self-Managed Mode” or “Self-Managed Cluster”, etc., as 
appropriate.

Cassandra
On Aug 7, 2020, 9:05 AM -0500, Cassandra Targett , wrote:
> The suggestion to use “managed” and maybe “self-managed” is an interesting 
> one. Do you think it’s possible some might confuse that with the other ways 
> we use managed - like the “managed-schema”, and “managed resources” (synonyms 
> and stop words)? Neither of those are cluster-specific, and I wonder if the 
> overlap in terminology would cause them to be conflated.
>
> Cassandra
> On Aug 6, 2020, 10:51 AM -0500, Ilan Ginzburg , wrote:
> > Both "legacy" and "SolrCloud" clusters are search server clusters. Seen 
> > from far enough, they look the same.
> >
> > In "legacy" the management code is elsewhere (developed by the client 
> > operating the cluster, running on other machines using a diferent logic and 
> > potentially another DB than Zookeeper) whereas in "SolrCloud" the 
> > management code is embedded in the search server(s) code and it happens 
> > that (currently) this code relies on Zookeeper.
> >
> > I see SolrCloud as a "managed cluster" vs. legacy that would be "Self 
> > managed" by the client, or "U manage" (non managed when looking at it from 
> > the Solr codebase perspective).
> >
> > Same idea as coordinated vs uncoordinated basically. I don't know why but I 
> > prefer "managed".
> >
> > Ilan
> >
> > > On Thu, Aug 6, 2020 at 5:49 PM Cassandra Targett  
> > > wrote:
> > > > On Aug 6, 2020, 10:22 AM -0500, Gus Heck , wrote:
> > > > > WRT the name "uncoordinated mode" I fear it could be read (or even 
> > > > > become known as) as "clumsy mode" which is humorous but possibly not 
> > > > > what we're going for :)
> > > >
> > > > I had also considered “non-coordinated”, and prefer it but couldn’t 
> > > > articulate why. The association of “uncoordinated" with clumsiness 
> > > > might be what was bugging me.
> > > > >  I'd perhaps suggest Cluster mode for SolrCloud though I'm not 
> > > > > entirely sure if Legacy Solr (in curren parlance) is not a "cluster" 
> > > > > too, cluster being a somewhat vague term. However Clustered Mode and 
> > > > > Legacy Mode seem more on target. I think "Legacy" could be changed 
> > > > > since we're not really planning on abandoning it (are we?), but
> > > >
> > > > One can have a cluster and not run SolrCloud. I think from an 
> > > > operations perspective, several servers all running Solr is considered 
> > > > a cluster, no matter what tools are being used to get them to talk to 
> > > > each other.
> > > >
> > > > I think “Legacy” (also used today already in some contexts) is 
> > > > problematic because there aren’t plans to abandon it. Also “Legacy 
> > > > replication” is pretty close to exactly what PULL replicas use to poll 
> > > > leaders and pull new index segments when needed. IOW, it’s not 
> > > > “legacy”, it’s very actively being used in a growing number of 
> > > > clusters. That might be an implementation detail users aren’t aware of, 
> > > > but I feel the term is really lacking mostly in that it just doesn’t 
> > > > say anything besides “it’s older”.
> > > > > the adjective there SHOULD communicate reduced functionality because 
> > > > > there are plenty of features that are cloud (cluster) only.
> > > >
> > > > In my view, the reduced functionality of non-SolrCloud clusters is 
> > > > mostly around coordination of requests, leader election, configs, and 

Re: Naming of non-SolrCloud clusters in the Ref Guide

[Cassandra Targett]

The suggestion to use “managed” and maybe “self-managed” is an interesting one. 
Do you think it’s possible some might confuse that with the other ways we use 
managed - like the “managed-schema”, and “managed resources” (synonyms and stop 
words)? Neither of those are cluster-specific, and I wonder if the overlap in 
terminology would cause them to be conflated.

Cassandra
On Aug 6, 2020, 10:51 AM -0500, Ilan Ginzburg , wrote:
> Both "legacy" and "SolrCloud" clusters are search server clusters. Seen from 
> far enough, they look the same.
>
> In "legacy" the management code is elsewhere (developed by the client 
> operating the cluster, running on other machines using a diferent logic and 
> potentially another DB than Zookeeper) whereas in "SolrCloud" the management 
> code is embedded in the search server(s) code and it happens that (currently) 
> this code relies on Zookeeper.
>
> I see SolrCloud as a "managed cluster" vs. legacy that would be "Self 
> managed" by the client, or "U manage" (non managed when looking at it from 
> the Solr codebase perspective).
>
> Same idea as coordinated vs uncoordinated basically. I don't know why but I 
> prefer "managed".
>
> Ilan
>
> > On Thu, Aug 6, 2020 at 5:49 PM Cassandra Targett  
> > wrote:
> > > On Aug 6, 2020, 10:22 AM -0500, Gus Heck , wrote:
> > > > WRT the name "uncoordinated mode" I fear it could be read (or even 
> > > > become known as) as "clumsy mode" which is humorous but possibly not 
> > > > what we're going for :)
> > >
> > > I had also considered “non-coordinated”, and prefer it but couldn’t 
> > > articulate why. The association of “uncoordinated" with clumsiness might 
> > > be what was bugging me.
> > > >  I'd perhaps suggest Cluster mode for SolrCloud though I'm not entirely 
> > > > sure if Legacy Solr (in curren parlance) is not a "cluster" too, 
> > > > cluster being a somewhat vague term. However Clustered Mode and Legacy 
> > > > Mode seem more on target. I think "Legacy" could be changed since we're 
> > > > not really planning on abandoning it (are we?), but
> > >
> > > One can have a cluster and not run SolrCloud. I think from an operations 
> > > perspective, several servers all running Solr is considered a cluster, no 
> > > matter what tools are being used to get them to talk to each other.
> > >
> > > I think “Legacy” (also used today already in some contexts) is 
> > > problematic because there aren’t plans to abandon it. Also “Legacy 
> > > replication” is pretty close to exactly what PULL replicas use to poll 
> > > leaders and pull new index segments when needed. IOW, it’s not “legacy”, 
> > > it’s very actively being used in a growing number of clusters. That might 
> > > be an implementation detail users aren’t aware of, but I feel the term is 
> > > really lacking mostly in that it just doesn’t say anything besides “it’s 
> > > older”.
> > > > the adjective there SHOULD communicate reduced functionality because 
> > > > there are plenty of features that are cloud (cluster) only.
> > >
> > > In my view, the reduced functionality of non-SolrCloud clusters is mostly 
> > > around coordination of requests, leader election, configs, and other 
> > > similar automated activities one does manually otherwise. So, I feel that 
> > > sort of proves my point - a word that conveys lack of coordination is a 
> > > good option for what it’s called. If there is a better antonym for 
> > > “coordinated”, I’m all for considering it but haven’t yet been able to 
> > > think of/find one.
> > >
> > > I think it’s important to think about what differentiates the two ways of 
> > > managing a Solr cluster and derive the naming from that. What features of 
> > > SolrCloud don’t exist in the non-SolrCloud approach? What words help us 
> > > generalize those gaps and can any of them be an appropriate name?
> > > >
> > > > -Gus
> > > >
> > > > On Thu, Aug 6, 2020 at 10:27 AM Cassandra Targett 
> > > >  wrote:
> > > > > The work in SOLR-14702 has left us with some awkward phrasing (which 
> > > > > is still better than what it was) around non-SolrCloud clusters that 
> > > > > I've offered to help fix.
> > > > >
> > > > > I think we've struggled for years to find a good name for 
> > > > > non-SolrCloud clusters a

Re: Naming of non-SolrCloud clusters in the Ref Guide

[Cassandra Targett]

On Aug 6, 2020, 10:22 AM -0500, Gus Heck , wrote:
> WRT the name "uncoordinated mode" I fear it could be read (or even become 
> known as) as "clumsy mode" which is humorous but possibly not what we're 
> going for :)

I had also considered “non-coordinated”, and prefer it but couldn’t articulate 
why. The association of “uncoordinated" with clumsiness might be what was 
bugging me.
>  I'd perhaps suggest Cluster mode for SolrCloud though I'm not entirely sure 
> if Legacy Solr (in curren parlance) is not a "cluster" too, cluster being a 
> somewhat vague term. However Clustered Mode and Legacy Mode seem more on 
> target. I think "Legacy" could be changed since we're not really planning on 
> abandoning it (are we?), but

One can have a cluster and not run SolrCloud. I think from an operations 
perspective, several servers all running Solr is considered a cluster, no 
matter what tools are being used to get them to talk to each other.

I think “Legacy” (also used today already in some contexts) is problematic 
because there aren’t plans to abandon it. Also “Legacy replication” is pretty 
close to exactly what PULL replicas use to poll leaders and pull new index 
segments when needed. IOW, it’s not “legacy”, it’s very actively being used in 
a growing number of clusters. That might be an implementation detail users 
aren’t aware of, but I feel the term is really lacking mostly in that it just 
doesn’t say anything besides “it’s older”.
> the adjective there SHOULD communicate reduced functionality because there 
> are plenty of features that are cloud (cluster) only.

In my view, the reduced functionality of non-SolrCloud clusters is mostly 
around coordination of requests, leader election, configs, and other similar 
automated activities one does manually otherwise. So, I feel that sort of 
proves my point - a word that conveys lack of coordination is a good option for 
what it’s called. If there is a better antonym for “coordinated”, I’m all for 
considering it but haven’t yet been able to think of/find one.

I think it’s important to think about what differentiates the two ways of 
managing a Solr cluster and derive the naming from that. What features of 
SolrCloud don’t exist in the non-SolrCloud approach? What words help us 
generalize those gaps and can any of them be an appropriate name?
>
> -Gus
>
> On Thu, Aug 6, 2020 at 10:27 AM Cassandra Targett  
> wrote:
> > The work in SOLR-14702 has left us with some awkward phrasing (which is 
> > still better than what it was) around non-SolrCloud clusters that I've 
> > offered to help fix.
> >
> > I think we've struggled for years to find a good name for non-SolrCloud 
> > clusters and we've used a number of variations: "legacy replication" (which 
> > it isn't, since PULL replicas use the same thing), "Standalone mode" (which 
> > it isn't because it's a cluster), now "leader/follower mode" (which could 
> > be confusing because SolrCloud has leaders).
> >
> > Yesterday I thought about what really differentiates a SolrCloud cluster 
> > and a non-SolrCloud cluster and it occurred to me that a key difference is 
> > the former is coordinated by ZooKeeper, while the latter is not. That led 
> > me to think that perhaps "coordinated mode" can someday be a better 
> > replacement for the term "SolrCloud", while "uncoordinated mode" could be a 
> > replacement today for all these other non-SolrCloud mode variations.
> >
> > I've opened https://issues.apache.org/jira/browse/SOLR-14716 and will 
> > create a branch for work in progress, but before I forge too far ahead, I 
> > want to draw attention to it first to give a chance for discussion so we're 
> > in agreement.
> >
> > Thanks,
> > Cassandra
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

Re: Naming of non-SolrCloud clusters in the Ref Guide

[Cassandra Targett]

Thanks, Ishan. Just to be clear, I’m not planning on replacing “SolrCloud” 
throughout at this time. I feel there are code changes that would need to 
correspond to that, so it’s a larger effort IMO. The way I put it in the Jira 
is:

“...Instead I'll augment the use of the word "SolrCloud" with clarification 
that this term means "coordinated mode". Later if we ever replace SolrCloud 
references in code and fully remove that name, the conceptual groundwork will 
have already been laid for users."

Cassandra
On Aug 6, 2020, 10:07 AM -0500, Ishan Chattopadhyaya 
, wrote:
> +1 Cassandra. These names are very appropriate. I'm glad we'll get rid of 
> "SolrCloud" name.
>
> > On Thu, 6 Aug, 2020, 7:57 pm Cassandra Targett,  
> > wrote:
> > > The work in SOLR-14702 has left us with some awkward phrasing (which is 
> > > still better than what it was) around non-SolrCloud clusters that I've 
> > > offered to help fix.
> > >
> > > I think we've struggled for years to find a good name for non-SolrCloud 
> > > clusters and we've used a number of variations: "legacy replication" 
> > > (which it isn't, since PULL replicas use the same thing), "Standalone 
> > > mode" (which it isn't because it's a cluster), now "leader/follower mode" 
> > > (which could be confusing because SolrCloud has leaders).
> > >
> > > Yesterday I thought about what really differentiates a SolrCloud cluster 
> > > and a non-SolrCloud cluster and it occurred to me that a key difference 
> > > is the former is coordinated by ZooKeeper, while the latter is not. That 
> > > led me to think that perhaps "coordinated mode" can someday be a better 
> > > replacement for the term "SolrCloud", while "uncoordinated mode" could be 
> > > a replacement today for all these other non-SolrCloud mode variations.
> > >
> > > I've opened https://issues.apache.org/jira/browse/SOLR-14716 and will 
> > > create a branch for work in progress, but before I forge too far ahead, I 
> > > want to draw attention to it first to give a chance for discussion so 
> > > we're in agreement.
> > >
> > > Thanks,
> > > Cassandra

Naming of non-SolrCloud clusters in the Ref Guide

[Cassandra Targett]

The work in SOLR-14702 has left us with some awkward phrasing (which is
still better than what it was) around non-SolrCloud clusters that I've
offered to help fix.

I think we've struggled for years to find a good name for non-SolrCloud
clusters and we've used a number of variations: "legacy replication" (which
it isn't, since PULL replicas use the same thing), "Standalone mode" (which
it isn't because it's a cluster), now "leader/follower mode" (which could
be confusing because SolrCloud has leaders).

Yesterday I thought about what really differentiates a SolrCloud cluster
and a non-SolrCloud cluster and it occurred to me that a key difference is
the former is coordinated by ZooKeeper, while the latter is not. That led
me to think that perhaps "coordinated mode" can someday be a better
replacement for the term "SolrCloud", while "uncoordinated mode" could be a
replacement today for all these other non-SolrCloud mode variations.

I've opened https://issues.apache.org/jira/browse/SOLR-14716 and will
create a branch for work in progress, but before I forge too far ahead, I
want to draw attention to it first to give a chance for discussion so we're
in agreement.

Thanks,
Cassandra

Re: [VOTE] Release Lucene/Solr 8.6.0 RC1

[Cassandra Targett]

I've pushed up the draft Solr Ref Guide for 8.6:
https://lucene.apache.org/solr/guide/8_6/.

This release will be the public debut of the redesign I finished a couple
months ago; if you have time, please explore around to find any issues I
may have missed.

On Wed, Jul 8, 2020 at 7:38 AM Noble Paul  wrote:

> SUCCESS! [1:07:35.754307]
>
> with Java 8
>
> +1
>
> On Wed, Jul 8, 2020 at 9:20 PM Noble Paul  wrote:
> >
> > it worked Uwe.
> > But there was a test failure
> >   [junit4] Tests with failures [seed: D6C8B0CC504808B4]:
> >[junit4]   -
> > org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore
> > (suite)
> > I believe it's just an isolated case of failure
> >
> > On Wed, Jul 8, 2020 at 7:49 PM Uwe Schindler  wrote:
> > >
> > > Hi,
> > >
> > >
> > >
> > > Policeman Jenkins Smoke tester was happy with your release (I tested
> already yesterday in the evening after your svn commit):
> > >
> > > https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/33/console
> > >
> > >
> > >
> > > SUCCESS! [1:23:18.912909]
> > >
> > >
> > >
> > > (Java 8 and Java 9)
> > >
> > >
> > >
> > > I will do some further checks by hand later today – as this is your
> first release. Will give my +1 later.
> > >
> > >
> > >
> > > Uwe
> > >
> > >
> > >
> > > -
> > >
> > > Uwe Schindler
> > >
> > > Achterdiek 19, D-28357 Bremen
> > >
> > > https://www.thetaphi.de
> > >
> > > eMail: u...@thetaphi.de
> > >
> > >
> > >
> > > From: Bruno Roustant 
> > > Sent: Wednesday, July 8, 2020 10:56 AM
> > > To: Solr/Lucene Dev 
> > > Subject: [VOTE] Release Lucene/Solr 8.6.0 RC1
> > >
> > >
> > >
> > > Please vote for release candidate 1 for Lucene/Solr 8.6.0
> > >
> > > The artifacts can be downloaded from:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
> > >
> > > You can run the smoke tester directly with this command:
> > >
> > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
> > >
> > > The vote will be open for at least 72 hours i.e. until 2020-07-11
> 09:00 UTC.
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > > Here is my +1
> >
> >
> >
> > --
> > -
> > Noble Paul
>
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: RoadMap?

[Cassandra Targett]

I’ll throw out the same suggestion I made when we had the same conversation 
about 6 months ago - we should make a 9.0 Roadmap wiki page, use it to write 
down & agree on goals, then add labels to Jira issues so we can go back to the 
wiki page and add queries which automatically query Jira and return issues and 
their status for each goal area. This use case is at least half the reason why 
a deep integration between Confluence and Jira exists.
On Jul 2, 2020, 1:39 PM -0500, Erick Erickson , wrote:
> There’s value IMO in having the discussion in one place rather than having to 
> search all of the JIRA tickets...
>
> > On Jul 2, 2020, at 2:30 PM, Gus Heck  wrote:
> >
> > Looking at 
> > https://issues.apache.org/jira/projects/SOLR?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page=unreleased
> >  maybe this is as simple as having one more field on our issues... 
> > Currently fix version denotes when something got fixed, perhaps a "target 
> > version" field could indicate when we want to fix it by. Then we just need 
> > a tag in jira and perhaps a branch.
> >
> > Alternately (or maybe additionally) we could make a "board" if that's 
> > easier to monitor.
> >
> > On Thu, Jul 2, 2020 at 2:02 PM Gus Heck  wrote:
> > Jira typically has features for designating what's in a release
> >
> > On Thu, Jul 2, 2020 at 1:55 PM Erick Erickson  
> > wrote:
> > I totally expect some things to bubble up when we try to release with 
> > Gradle, the tarball being one. I don’t think that’s a very big issue, but 
> > if you have lots of “not very big” issues they do add up.
> >
> > That said, yeah, I do think it’s time to start getting a handle on 9.0. 
> > Pulling Ant out of the build system is another possibility.
> >
> > Solr as a TLP? Or is that Solr 10? Or does it even have to be as of a major 
> > release?
> >
> > Sound like a Wiki page or some such to me…
> >
> > Erick
> >
> > > On Jul 2, 2020, at 1:07 PM, Andrzej Białecki  wrote:
> > >
> > > Autoscaling is another big item, but I think we have to put it into 9x, 
> > > it’s a critical (and critically broken) functionality. We’re making some 
> > > progress with Ilan and Noble so I’m cautiously optimistic.
> > >
> > > > On 2 Jul 2020, at 18:58, Gus Heck  wrote:
> > > >
> > > > Should we have one?
> > > >
> > > > With 9x having java 11 and gradle migrations on the dev side, and about 
> > > > to have a significant round of deprecations/removals and migrations to 
> > > > plugin for things such as CDCR, DIH etc (see 
> > > > https://issues.apache.org/jira/browse/SOLR-13442 and 
> > > > https://issues.apache.org/jira/browse/SOLR-14022) some of which may(?) 
> > > > need a replacement (i.e. CDCR?) or ways ot easily re-enable (i.e. 
> > > > streaming) before 9x is able to be released. Plus there's been talk of 
> > > > a revamped UI...
> > > >
> > > > I'm worried that there is a danger that 9x will continue to diverge and 
> > > > pick up major changes, but always have something big in progress and 
> > > > never be able to release.
> > > >
> > > > Perhaps we should attempt to put a box around the things that need to 
> > > > happen for 9x, and begin targeting any larger projects that come up at 
> > > > 10x? Among other things the gradle work probably can't be complete 
> > > > until someone has gone through a release using it. (I don't think we 
> > > > build the tarballs in gradle yet for example, unless that got added 
> > > > recently)
> > > >
> > > > -Gus
> > > >
> > > > --
> > > > http://www.needhamsoftware.com (work)
> > > > http://www.the111shift.com (play)
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: 8.6 release

[Cassandra Targett]

> >
> > > > > > > > >
> > > > > > > > > I should be done with this issue by eod today. In case you 
> > > > > > > > > have no objection, I would like to merge this issue after you 
> > > > > > > > > cut the branch today (and before you spin the RC).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Ishan
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Jun 30, 2020 at 6:20 AM Joel Bernstein 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Hi Bruno,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Andrzej and I decided that SOLR-14537 is headed to master to 
> > > > > > > > > bake for a while and won't make it into the 8.6 release. So 
> > > > > > > > > please feel free to cut the branch when ready.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Joel Bernstein
> > > > > > > > >
> > > > > > > > > http://joelsolr.blogspot.com/
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Jun 29, 2020 at 6:13 AM Andrzej Białecki 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > I wold like to include SOLR-14537 in 8.6 (it’s already 
> > > > > > > > > tagged), the patch is ready and I’m just waiting for Joel to 
> > > > > > > > > finish performance testing.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 27 Jun 2020, at 04:59, Tomás Fernández Löbbe 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I tagged SOLR-14590 for 8.6, The PR is ready for review and I 
> > > > > > > > > plan to merge it soon
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jun 26, 2020 at 12:54 PM Andrzej Białecki 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Jan,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I just removed SOLR-14182 from 8.6, this needs proper 
> > > > > > > > > back-compat shims and testing, and I don’t have enough time 
> > > > > > > > > to get it done properly for 8.6.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 26 Jun 2020, at 13:37, Jan Høydahl  
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Unresolved Solr issues tagged with 8.6:
> > > > > > > > >
> > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%208.6
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > SOLR-14593   Package store API to

Re: 8.6 release

[Cassandra Targett]

I started looking at the Ref Guide for 8.6 to get it ready, and notice there 
are no Upgrade Notes in `solr-upgrade-notes.adoc` for 8.6. Is it really true 
that none are needed at all?

I’ll add what I usually do about new features/changes that maybe wouldn’t 
normally make the old Upgrade Notes section, I just find it surprising that 
there weren’t any devs who thought any of the 100 or so Solr changes warrant 
any user caveats.
On Jun 17, 2020, 12:27 PM -0500, Tomás Fernández Löbbe , 
wrote:
> +1. Thanks Bruno
>
> > On Wed, Jun 17, 2020 at 6:22 AM Mike Drob  wrote:
> > > +1
> > >
> > > The release wizard python script should be sufficient for everything. If 
> > > you run into any issues with it, let me know, I used it for 8.5.2 and 
> > > think I understand it pretty well.
> > >
> > > > On Tue, Jun 16, 2020 at 8:31 AM Bruno Roustant 
> > > >  wrote:
> > > > > Hi all,
> > > > >
> > > > > It’s been a while since we released Lucene/Solr 8.5.
> > > > > I’d like to volunteer to be a release manager for an 8.6 release. If 
> > > > > there's agreement, then I plan to cut the release branch two weeks 
> > > > > today, on June 30th, and then to build the first RC two days later.
> > > > >
> > > > > This will be my first time as release manager so I'll probably need 
> > > > > some guidance. Currently I have two resource links on this subject:
> > > > > https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo
> > > > > https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#releasewizardpy
> > > > > If you have more, please share with me.
> > > > >
> > > > > Bruno

Re: Support to Solr 8.4.1 version

[Cassandra Targett]

I work at Lucidworks but not on that team, so take this with a grain of salt: 
It seems they simply neglected to update the tags & compatibility table. There 
is a 3.8.0 version of the .jar on Maven Central: 
https://search.maven.org/artifact/com.lucidworks.spark/spark-solr/3.8.0/jar, 
which if you look at the commit you linked to is the version in the pom.xml 
that was updated to support 8.4.1.  Alternatively, it looks pretty simple to 
build it locally if you prefer.

In the future, please take such questions to the project itself so you’re sure 
to reach the people who can actually help. If the organization in the path of 
the project in GitHub is not “apache”, it’s not officially managed by the 
Lucene project.
On Jun 22, 2020, 3:13 PM -0500, Shawn Heisey , wrote:
> On 6/22/2020 1:25 PM, Karthik K G wrote:
> > It would be helpful if we can get support for the spark-solr connector
> > to Solr version 8.4.1.
> >
> > Could you please let us know a tentative date when the latest version
> > with this support can be released. Many of us will be unblocked with
> > this release.
>
> I looked up the spark-solr connector. That appears to be a product from
> Lucidworks. Lucidworks is a commercial entity that releases products
> incorporating Solr. You will need to contact Lucidworks for help with
> their products. This mailing list does not support them.
>
> Thanks,
> Shawn
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: Public vs None Security Level on JIRA issues?

[Cassandra Targett]

I found hundreds of issues that had not been cleared the last time I did it
a couple months ago, dating back months. Enough that I assumed it had not
ever been added to any release instructions.

Either there is a discrepancy between releaseWizard.py and the wiki
ReleaseToDo that's causing it to be skipped in some cases, or sometimes an
RM is occasionally unable to complete all steps for whatever reason(s).

On Thu, May 21, 2020 at 9:52 AM Mike Drob  wrote:

> This is already present as a step in releaseWizard.py - Release Checklist
> > (9) Tasks to do after release > (10) > Clear Security Level of Public
> Solr JIRA Issues
>
> On Thu, May 21, 2020 at 9:49 AM David Smiley 
> wrote:
>
>> Also, I proposed this being added to our release process as well so that
>> it happens systemically, and so that issues referred to from any release
>> are more easily reachable.
>> ~ David
>>
>>
>> On Thu, May 21, 2020 at 10:38 AM Cassandra Targett 
>> wrote:
>>
>>> Yes, this is a known issue with Jira and the use of security levels.
>>> Atlassian (the maker of Jira) has known about it for years and has not
>>> fixed it yet.
>>>
>>> This was last discussed about a year ago and that thread has an
>>> explanation:
>>> https://lists.apache.org/thread.html/e1ca40af3e4f0c45c1ed2094471fe01aa6e5a835f2a5583b7c3b28a4%40%3Cdev.lucene.apache.org%3E
>>> .
>>>
>>> It basically boils down to the Jira query engine does not default to
>>> finding issues with either "none" (which is really NULL in Jira's database)
>>> or "public". If you don't define the security level field in your search,
>>> it only returns issues with no value (displayed as "none") in that field,
>>> which omits all the issues that do have a value in that field. It's dumb.
>>>
>>> The only solution is to periodically bulk edit the "public" issues so
>>> they have security level "none". I do it from time to time when I have time
>>> and remember, but not sure if anyone else does.
>>>
>>> Cassandra
>>>
>>> On Thu, May 21, 2020 at 8:50 AM Colvin Cowie 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> Sorry if this has been raised before, I could find it.
>>>> I was looking at issues that I had reported on JIRA and I was surprised
>>>> to see that the list of issues was different when I was logged in vs logged
>>>> out, since none of the issues are confidential.
>>>>
>>>>
>>>> https://issues.apache.org/jira/browse/SOLR-14421?jql=project%20%3D%20SOLR%20AND%20reporter%20in%20(cjcowie)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>>>
>>>> The JIRA help has this to say about security levels:
>>>>
>>>> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#SecurityLevels
>>>> Security Levels
>>>>
>>>> An issue has a security level which indicates which users are able to
>>>> view the issue. The currently defined security levels are listed below. In
>>>> addition, you can add more security levels in the administration section.
>>>> *Private (Security Issue)*Private Issue viewable by the reporter and
>>>> those in the project PMC Role *Public*Default Security Level. Issues
>>>> are Public
>>>>
>>>> Which to me would suggest that None and Public are the same thing, and
>>>> that Public issues would be visible to people who are not signed into JIRA
>>>> - which they are. *Except* they are not searchable.
>>>>
>>>> For an issue marked as Public I can visit it directly if I have the
>>>> issue number, but I cannot search for its text. As soon as I change the
>>>> Security Level to None on an issue its text is searchable.
>>>>
>>>> That doesn't seem right to me, but if it is working as intended, then
>>>> maybe the help text could be updated?
>>>>
>>>> Colvin
>>>>
>>>

Re: Public vs None Security Level on JIRA issues?

[Cassandra Targett]

Yes, this is a known issue with Jira and the use of security levels.
Atlassian (the maker of Jira) has known about it for years and has not
fixed it yet.

This was last discussed about a year ago and that thread has an
explanation:
https://lists.apache.org/thread.html/e1ca40af3e4f0c45c1ed2094471fe01aa6e5a835f2a5583b7c3b28a4%40%3Cdev.lucene.apache.org%3E
.

It basically boils down to the Jira query engine does not default to
finding issues with either "none" (which is really NULL in Jira's database)
or "public". If you don't define the security level field in your search,
it only returns issues with no value (displayed as "none") in that field,
which omits all the issues that do have a value in that field. It's dumb.

The only solution is to periodically bulk edit the "public" issues so they
have security level "none". I do it from time to time when I have time and
remember, but not sure if anyone else does.

Cassandra

On Thu, May 21, 2020 at 8:50 AM Colvin Cowie 
wrote:

> Hello,
>
> Sorry if this has been raised before, I could find it.
> I was looking at issues that I had reported on JIRA and I was surprised to
> see that the list of issues was different when I was logged in vs logged
> out, since none of the issues are confidential.
>
>
> https://issues.apache.org/jira/browse/SOLR-14421?jql=project%20%3D%20SOLR%20AND%20reporter%20in%20(cjcowie)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> The JIRA help has this to say about security levels:
>
> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#SecurityLevels
> Security Levels
>
> An issue has a security level which indicates which users are able to view
> the issue. The currently defined security levels are listed below. In
> addition, you can add more security levels in the administration section.
> *Private (Security Issue)*Private Issue viewable by the reporter and
> those in the project PMC Role *Public*Default Security Level. Issues are
> Public
>
> Which to me would suggest that None and Public are the same thing, and
> that Public issues would be visible to people who are not signed into JIRA
> - which they are. *Except* they are not searchable.
>
> For an issue marked as Public I can visit it directly if I have the issue
> number, but I cannot search for its text. As soon as I change the Security
> Level to None on an issue its text is searchable.
>
> That doesn't seem right to me, but if it is working as intended, then
> maybe the help text could be updated?
>
> Colvin
>

Re: Overseer documentation

[Cassandra Targett]

Agreed this is great and difficult work, Ilan. Thanks so much for taking it on.

I wonder if some of this maybe should end up in Javadocs? If those classes 
don’t say what they’re doing or seem incomplete (and I have no idea what they 
say about themselves) then we should consider maybe using some of this to 
improve that?

I don’t have much to say about the content - I might understand this all better 
if I read a doc like this though! - except to reply to David’s question to me:
On Apr 23, 2020, 2:36 PM -0500, David Smiley , wrote:


>
> This is "developer documentation".  Cassandra:  I see you created 
> solr/dev-docs/ and I suppose this would best belong there?  Mark Miller had 
> tried Confluence.  Pros/cons there.  I want to ensure readers of the code in 
> Overseer (and maybe other key class or two) notice this dev documentation.  
> Should I add a http link to the GitHub location of the dev doc markdown, or 
> do you recommend something else?
>

Well, I added the directories but I didn’t just make it up - we had a thread in 
the Dev list about doing it and since no one else moved to make it happen and I 
had some internal docs to write when I handed off PMC chair to Anshum, I did 
it. But besides being what we already said we wanted to do, I think it should 
go in our source code for at least all the same reasons we put the Ref Guide in 
the source - that’s where we already are, that’s where contributors need to be, 
and we can ensure the docs are properly relevant to the versions via our 
branching approach.

I have a Google Docs add-on which can convert Google docs to Asciidoc format, 
which for a document this complex I would recommend as a format. The add-on is 
not going to do this doc perfectly, but will get 50% or more the way there. I’d 
be willing to give it a try, but if people want a mix of Asciidoc + Markdown 
formatted files and want to convert this to Markdown, by all means go for it.

Re: Solr Admin UI Refresh 2020

[Cassandra Targett]

 > > > > > > > > > > > > > On Fri, 10 Apr, 2020, 8:33 pm Marcus Eagan, 
> > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > I agree with you. 
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, Apr 10, 2020 at 06:22 David Smiley 
> > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > I disagree that "package management 
> > > > > > > > > > > > > > > > > > > frameworks are for loading non-essential 
> > > > > > > > > > > > > > > > > > > features or features not enabled by 
> > > > > > > > > > > > > > > > > > > default".
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I don't think the proposal of the UI 
> > > > > > > > > > > > > > > > > > > being a "package" (in the new package 
> > > > > > > > > > > > > > > > > > > system) implies that the UI (or _any_ 
> > > > > > > > > > > > > > > > > > > package) is not a highly valuable package 
> > > > > > > > > > > > > > > > > > > that is so highly valuable that we want 
> > > > > > > > > > > > > > > > > > > it installed by default.  Noble and I 
> > > > > > > > > > > > > > > > > > > were brainstorming on some ideas where 
> > > > > > > > > > > > > > > > > > > even much of Solr's internal instances of 
> > > > > > > > > > > > > > > > > > > plugin interfaces (e.g. query parsers, 
> > > > > > > > > > > > > > > > > > > etc.) might even be a new "core" package 
> > > > > > > > > > > > > > > > > > > or some-such.  The value in putting much 
> > > > > > > > > > > > > > > > > > > of Solr in a package, 1st party, is 
> > > > > > > > > > > > > > > > > > > separation of concerns. and better 
> > > > > > > > > > > > > > > > > > > classpath management.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think it's "essential" that a UI ship 
> > > > > > > > > > > > > > > > > > > with Solr by default -- meaning, without 
> > > > > > > > > > > > > > > > > > > the user having to take any additional 
> > > > > > > > > > > > > > > > > > > steps whatsoever.  As Jan said it's been 
> > > > > > > > > > > > > > > > > > > this way a long time.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > ~ David Smiley
> > > > > > > > > > > > > > > > > > > Apache Lucene/Solr Search Developer
> > > > > > > > > > > > > > > > > > > http://www.linkedin.com/in/davidwsmiley
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Fri, Apr 10, 2020 at 1:35 AM Marcus 
> > > > > > > > > > > > > > > > > > > > Eagan  wrote:
> > > > > > > > > > > > > > > > > > > > > I think package management frameworks 
> > > > > > > > > > &g

Re: [VOTE] Release Lucene/Solr 8.5.1 RC1

[Cassandra Targett]

Jan, I also see the same text you hoped to fix with SOLR-14359.

I think I might see a clue to the problem - in your PR you updated 
“angular-chosen.min.js” but the head section of index.html also calls 
“chosen.jquery.min.js”.

The problematic text in the drop downs is found in a  element enclosed in 
an  element which has classes defined that are only found in 
“chosen.jquery.min.js” - I suspect this file also needs to be updated in some 
way. Here’s the rendered HTML:

https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
> >
> > The vote will be open for at least 72 hours i.e. until 2020-04-15 11:00 UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1
> >
> > SUCCESS! [1:02:16.691004]
> >
>

Re: Solr Admin UI Refresh 2020

[Cassandra Targett]

Thanks for your message, Gus. You touched on things I was thinking this morning 
as I caught up to the thread, and had started to draft a message about.

I feel like there is an assumption underlying some of our discussion about 
packages that says a feature or whatever has to either part of our core 
codebase or 100% maintained by someone “outside” the community (by which I mean 
someone who is not a committer and/or operates completely independently from 
the rest of the project activities).

But it’s important to remember there’s nothing inherent in the package concept 
that says a package can't be wholly maintained/distributed/supported by the 
Lucene PMC and our community of committers and contributors. It’s not uncommon 
for software to have a base package of the core software and also plugins that 
most users would consider “essential”, maintained by the same people making the 
core, but which are added after the base install. There would be details to 
work out in terms of how we manage that, but none of those are technically 
impossible. I don’t think we only have a binary choice (3rd party package or 
part of Solr core).

In fact, I’d go so far as to say I suspect the only way packages are going to 
see any real traction is if we take the lead in creating and maintaining a few 
to show the way forward for everyone else who may be interested in doing the 
same. The package concept introduces an idea of a Solr ecosystem that has not 
really existed to date and like all new ecosystems (communities), it needs some 
degree of nurturing to grow or it will not take off.

To bring it back around to the UI, though, I agree we need to decide: is a UI 
important? I would argue that it is. I regularly talk to users whose Solr 
knowledge and experience are quite advanced yet who still rely entirely on the 
UI to carry out basic tasks. It’s just easier - less to remember, don’t need to 
look up a command, etc. Persistent problems with performance of the UI in large 
clusters and gaping holes in functionality are deeply frustrating to those 
users.

Because it is important to our users, even if any new UI ends up living outside 
our community, it will need our explicit approval in some form or we’re going 
to hear complaints until the end of time that Solr doesn’t have a UI (or worse, 
we “took away” the UI). Without our ongoing endorsement and blessing it will 
just be another toy maintained by “somebody” (no offense, Marcus) until he is 
forced to abandon it due to lack of user interest and/or lack of personal time 
to do all the heavy lifting by himself.

Cassandra
On Apr 9, 2020, 11:32 AM -0500, Erick Erickson , wrote:
> Gus:
>
> Very thoughtful post. I think you raise an _extremely_ important point about 
> “how critical is the UI?” And by extension other packages. If they’re 
> critical to Solr, the question of how to keep them in sync becomes paramount.
>
> I agree that the admin UI is important, if we have a mechanism to insure it’s 
> kept in sync with the release that would be near the to of my list.
>
> Best,
> Erick
>
> > On Apr 9, 2020, at 12:06 PM, Gus Heck  wrote:
> >
> > In my view this brings us up against a bit of an existential question. How 
> > do we ensure quality of packages that are key to Solr? I'm sure that there 
> > are folks who don't find the UI very useful, but it's important to others. 
> > The rationale that "elastic keeps their's separate" has to be tempered by 
> > the actual real differences between Elastic and Solr. Elastic has a 
> > corporate sponsor, a coordinated road map, and explicitly ensures that all 
> > the bits that are maintained separately work together (so that they don't 
> > have excessive support costs or bad first experiences that impact their 
> > bottom line etc.).
> >
> > Solr is in a different place however, and we need to carefully examine the 
> > question of whether something that works for Elastic works for us. 
> > Lucidworks and several other large companies do spend a lot of money on 
> > developers that contribute to Solr, but there is no organization around 
> > multiple components that MUST work together. Another example of this is 
> > Solr and Lucene, and our defense against a lack of coordination of 
> > components in that case has been to unify them into a single release 
> > package.
> >
> > So IMHO we need to answer 2 questions:
> > 1.) Do we consider the UI important. If I'm alone or in a minority in 
> > feeling it's important, then so be it and it doesn't really matter what we 
> > do. (maybe a vote?)
> > 2.) If we make it "a package" how do we ensure that important packages such 
> > as the UI are never broken by a new release.
> >
> > IMHO I don't thing we should tolerate a situation where things we consider 
> > important are broken frequently.
> >
> > For my part obviously my answer to 1 is "yes" :). As for 2, one thing that 
> > comes to mind is what the Ant project did (may still do?) with (and my 
> > memory from 15 years ago 

Re: Lucene/Solr 8.5.1 bugfix release

[Cassandra Targett]

Should we consider backporting SOLR-14367 (the most recent Tika upgrade)? It 
addresses a CVE in Tika, and while I think we usually avoid changing 3rd party 
component versions in patch releases, but maybe we should in this case? The 
upgrade also looks like it was pretty straightforward (drop-in replacement).

Cassandra
On Apr 2, 2020, 12:47 PM -0500, Ignacio Vera , wrote:
> Hi,
>
> I propose a quick 8.5.1 bugfix release and I volunteer as RM. The main 
> motivation for this release is LUCENE-9300 where Jim addressed a serious bug 
> that can lead to data corruption when merging indices via IW#addIndices.
>
> If there are no objections I am planning to create a RC early next week.
>
> Best regards,
>
> Ignacio
>
>

Re: 8.5 release

[Cassandra Targett]

I’ll look to add the release instructions soon. There is a page in the Ref 
Guide that describes how to do it (it’s basically the same as javadocs, just a 
different ant/gradle target).

I also created a new top-level page in Solr’s Confluence for Release Notes: 
https://cwiki.apache.org/confluence/display/SOLR/Release+Notes. I only moved 
8.x and a couple 7.x notes there for now (it’s a bit tedious to move them, but 
anyone would be welcome to keep going) so we can use that spot to put them from 
now on. I didn’t check, though, if Lucene’s Confluence has the same problem of 
notes being buried? Sorry to half-complete the task, I was looking for Solr's 
notes and got annoyed I can never find them quickly.

Cassandra
On Mar 17, 2020, 5:50 AM -0500, Alan Woodward , wrote:
> If you add the release instructions to the ReleaseTodo page on cwiki then the 
> RM should be able to follow them.  I can look into adding them to the release 
> wizard as well.
>
> > On 16 Mar 2020, at 15:15, Cassandra Targett  wrote:
> >
> > What do we need to do to get pushing the Ref Guide up as part of the RM 
> > process? It’s super simple now, but I’m not sure what needs to change to 
> > make it happen regularly as part of release.
> >
> > Cassandra
> > On Mar 16, 2020, 3:48 AM -0500, Alan Woodward , wrote:
> > > Let’s keep both pages as Draft for now - one advantage of Cwiki over moin 
> > > is that we can delay publishing our release notes until the release has 
> > > actually happened.
> > >
> > > > On 16 Mar 2020, at 08:20, Mikhail Khludnev  wrote:
> > > >
> > > >
> > > > Alan, I've added a point. Should I click [Publish]?
> > > >
> > > > > On Fri, Mar 13, 2020 at 5:31 PM Alan Woodward  
> > > > > wrote:
> > > > > > That’s the one, thank you Jan!  I’ve cloned it and made minimal 
> > > > > > changes to update it to 8.5, it still needs the release highlights 
> > > > > > adding in though.  Draft page is available here:
> > > > > > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
> > > > > >
> > > > > > We should definitely make a top-level page for these, they 
> > > > > > currently sit under ‘Old Wiki’ which doesn’t seem right at all.
> > > > > >
> > > > > > > On 13 Mar 2020, at 11:20, Jan Høydahl  
> > > > > > > wrote:
> > > > > > >
> > > > > > > Perhaps this is the one you are looking for? 
> > > > > > > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84
> > > > > > >
> > > > > > > We should probably make a top-level page «Release Notes» under 
> > > > > > > which we can attach future release notes.
> > > > > > >
> > > > > > > Jan
> > > > > > >
> > > > > > > > 12. mar. 2020 kl. 17:24 skrev Alan Woodward 
> > > > > > > > :
> > > > > > > >
> > > > > > > > While I wait for the smoke tester to finish, I’ve been working 
> > > > > > > > on release notes.  The ReleaseTodo still refers to the old 
> > > > > > > > wiki, and release notes are on CWiki now, so I’m flying 
> > > > > > > > slightly blind.  Looking at what was done for the previous 
> > > > > > > > release, I’ve created a draft note for lucene which can be 
> > > > > > > > inspected and edited here:
> > > > > > > >
> > > > > > > > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
> > > > > > > >
> > > > > > > > For Solr, the 8.4 release note on CWiki points to a section on 
> > > > > > > > https://lucene.apache.org/solr/news.html  but it’s not entirely 
> > > > > > > > clear where this section has come from or where it should be 
> > > > > > > > drafted.  Can anybody enlighten me?
> > > > > > > >
> > > > > > > > > On 11 Mar 2020, at 09:20, Alan Woodward 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Sure, go ahead
> > > > > > > > >
> > > > > > > > > > On

Re: 8.5 release

[Cassandra Targett]

What do we need to do to get pushing the Ref Guide up as part of the RM 
process? It’s super simple now, but I’m not sure what needs to change to make 
it happen regularly as part of release.

Cassandra
On Mar 16, 2020, 3:48 AM -0500, Alan Woodward , wrote:
> Let’s keep both pages as Draft for now - one advantage of Cwiki over moin is 
> that we can delay publishing our release notes until the release has actually 
> happened.
>
> > On 16 Mar 2020, at 08:20, Mikhail Khludnev  wrote:
> >
> >
> > Alan, I've added a point. Should I click [Publish]?
> >
> > > On Fri, Mar 13, 2020 at 5:31 PM Alan Woodward  
> > > wrote:
> > > > That’s the one, thank you Jan!  I’ve cloned it and made minimal changes 
> > > > to update it to 8.5, it still needs the release highlights adding in 
> > > > though.  Draft page is available here:
> > > > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
> > > >
> > > > We should definitely make a top-level page for these, they currently 
> > > > sit under ‘Old Wiki’ which doesn’t seem right at all.
> > > >
> > > > > On 13 Mar 2020, at 11:20, Jan Høydahl  wrote:
> > > > >
> > > > > Perhaps this is the one you are looking for? 
> > > > > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84
> > > > >
> > > > > We should probably make a top-level page «Release Notes» under which 
> > > > > we can attach future release notes.
> > > > >
> > > > > Jan
> > > > >
> > > > > > 12. mar. 2020 kl. 17:24 skrev Alan Woodward :
> > > > > >
> > > > > > While I wait for the smoke tester to finish, I’ve been working on 
> > > > > > release notes.  The ReleaseTodo still refers to the old wiki, and 
> > > > > > release notes are on CWiki now, so I’m flying slightly blind.  
> > > > > > Looking at what was done for the previous release, I’ve created a 
> > > > > > draft note for lucene which can be inspected and edited here:
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
> > > > > >
> > > > > > For Solr, the 8.4 release note on CWiki points to a section on 
> > > > > > https://lucene.apache.org/solr/news.html  but it’s not entirely 
> > > > > > clear where this section has come from or where it should be 
> > > > > > drafted.  Can anybody enlighten me?
> > > > > >
> > > > > > > On 11 Mar 2020, at 09:20, Alan Woodward  
> > > > > > > wrote:
> > > > > > >
> > > > > > > Sure, go ahead
> > > > > > >
> > > > > > > > On 10 Mar 2020, at 19:22, David Smiley 
> > > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Can I assume it's no big deal to post a solr-ref-guide 
> > > > > > > > documentation improvement on the release branch irrespective of 
> > > > > > > > whenever you precisely do the RC?
> > > > > > > >
> > > > > > > > ~ David Smiley
> > > > > > > > Apache Lucene/Solr Search Developer
> > > > > > > > http://www.linkedin.com/in/davidwsmiley
> > > > > > > >
> > > > > > > >
> > > > > > > > > On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein 
> > > > > > > > >  wrote:
> > > > > > > > > > I just updated solr/CHANGES.txt as I missed something. If 
> > > > > > > > > > you've already created the RC then it will be there in case 
> > > > > > > > > > of a respin.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Joel Bernstein
> > > > > > > > > > http://joelsolr.blogspot.com/
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > > done. Thank you!
> > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward 
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > Go ahead, I’ll start the release build once it’s in.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 10 Mar 2020, at 07:26, Ignacio Vera 
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Alanm
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Is it  possible to backport 
> > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/LUCENE-9263 
> > > > > > > > > > > > > > > for the 8.5 release, I push it tester day and CI 
> > > > > > > > > > > > > > > is happy.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein 
> > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Finished the backport for 
> > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/SOLR-14073.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Joel Bernstein
> > > > > > > > > > > > > > > > > 

RE: [VOTE] Release Lucene/Solr 8.5.0 RC1

[Cassandra Targett]

I pushed the Solr Ref Guide DRAFT up this morning (thought I did it on Friday, 
sorry): https://lucene.apache.org/solr/guide/8_5/.

Cassandra
On Mar 15, 2020, 6:06 PM -0500, Uwe Schindler , wrote:
> Hi,
>
> I instructed Policeman Jenkins to automatically test the release for me, the 
> result (Java 8 / Java 9 combined Smoketesting):
>
> SUCCESS! [1:24:47.422173]
> (see https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/30/console)
>
> I also downloaded the artifacts and tested manually:
> - Solr starts and stops perfectly on Windows with whitespace in path name: 
> Java 8, Java 11 and Java 14 (coming out soon)
> - Javadocs of Lucene look fine
> - JAR files look good
> - All links to repos in pom.xml and ant use HTTPS
>
> So I am fine with releasing this.
> +1 to RELEASE!
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Alan Woodward 
> > Sent: Friday, March 13, 2020 3:27 PM
> > To: dev@lucene.apache.org
> > Subject: [VOTE] Release Lucene/Solr 8.5.0 RC1
> >
> > Please vote for release candidate 1 for Lucene/Solr 8.5.0
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1-
> > rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1-
> > rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42
> >
> > The vote will be open for three working days i.e. until next Tuesday, 
> > 2020-03-
> > 18 14:00 UTC.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here is my +1
> > -
> > 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: Solr: "Upgrade Notes" no longer in CHANGES.txt; See Ref Guide

[Cassandra Targett]

Thanks David, that helps.

For sure we’ll have a separate page for 9.0, likely along the lines as we have 
for 6, 7, and 8. Maybe also starting in 9.0 I’ll revisit the idea of doing 
separate upgrade note pages too, but won’t do it now.
On Mar 3, 2020, 4:10 PM -0600, David Smiley , wrote:
>
> > On Tue, Mar 3, 2020 at 4:35 PM Cassandra Targett  
> > wrote:
> > > The Release Notes (feature/improvement highlights) will still be in 
> > > CWIKI, right (even if just for now)?
> >
> > Yes I think so.  This really should be strictly a major highlights kind of 
> > info -- somewhat brief.  We rely on the ref guide + CHANGES.txt for deeper 
> > info.
> >
> > > Do we want to try to include the Version of Major Components section in 
> > > the Ref Guide, or are we dropping it entirely?
> >
> > Drop entirely IMO.  We have separate pages with info for ZK & Java which 
> > are probably the only pertinent version numbers of related software.
> >
> > > Do we want to try to separate out the upgrade notes for each version into 
> > > separate pages at this point, or also save that as a possibility for 
> > > later?
> >
> > No opinion; your call.  Maybe start a new page at 9.0.
> >
> > ~ David
> >
> > > Thanks again -
> > >
> > > Cassandra
> > > On Feb 2, 2020, 11:16 PM -0600, David Smiley , 
> > > wrote:
> > > > I want to draw attention to an issue I've worked on that makes some 
> > > > notable changes to CHANGES.txt maintenance: 
> > > > https://issues.apache.org/jira/browse/SOLR-14149
> > > > It's already code-reviewed by Jan and Cassandra approves (a huge fan).  
> > > > In particular I want to draw attention to the move of the "upgrade 
> > > > notes" subject to be strictly in the Solr Ref Guide which goes here: 
> > > > https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/solr-upgrade-notes.adoc
> > > >   You can see the PR to see what it looks like.  I repeat, NO MORE 
> > > > adding upgrade notes to the top of CHANGES.txt.  If you have opposing 
> > > > views on this, please speak up in JIRA.  I plan to commit the issue in 
> > > > a couple days.
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley

Re: Solr: "Upgrade Notes" no longer in CHANGES.txt; See Ref Guide

[Cassandra Targett]

I’m just finally getting around to looking at this to prep for 8.5. Thanks 
David & Jan for working on this, I think it will help.

I have a few questions for this release:

The Release Notes (feature/improvement highlights) will still be in CWIKI, 
right (even if just for now)?

Do we want to try to include the Version of Major Components section in the Ref 
Guide, or are we dropping it entirely?

Do we want to try to separate out the upgrade notes for each version into 
separate pages at this point, or also save that as a possibility for later?

Thanks again -

Cassandra
On Feb 2, 2020, 11:16 PM -0600, David Smiley , wrote:
> I want to draw attention to an issue I've worked on that makes some notable 
> changes to CHANGES.txt maintenance: 
> https://issues.apache.org/jira/browse/SOLR-14149
> It's already code-reviewed by Jan and Cassandra approves (a huge fan).  In 
> particular I want to draw attention to the move of the "upgrade notes" 
> subject to be strictly in the Solr Ref Guide which goes here: 
> https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/solr-upgrade-notes.adoc
>   You can see the PR to see what it looks like.  I repeat, NO MORE adding 
> upgrade notes to the top of CHANGES.txt.  If you have opposing views on this, 
> please speak up in JIRA.  I plan to commit the issue in a couple days.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley

Re: Propose JIRA "Fix Version" remove from create-issue screen

[Cassandra Targett]

Yes, you’re correct.

We currently have only one screen used for create, edit, and view in each 
project. To change which fields show in any one of those views, we need another 
screen. Only Jira administrators can make a screen and update the screen scheme 
to use it, and, for our Jira, only Infra are Jira administrators.
On Feb 7, 2020, 9:56 AM -0600, David Smiley , wrote:
> Cassandra:
> I believe you have more JIRA administrative experience than I.  I notice Solr 
> has one "screen" used for create, edit, and view.  "SOLR-JIRA-PROJECT" is the 
> name of the screen.  It appears I need to request that a JIRA administrator 
> create a new screen for us that is associated only with the "create issue" 
> operation of the "screen scheme".  Do you agree?  Likewise for the Lucene 
> project.  I'll go file an Infra ticket.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> > On Mon, Feb 3, 2020 at 9:04 AM Eric Pugh  
> > wrote:
> > > +1 as well.  I have seen new contributors struggle with what setting that 
> > > means...   It can also set an expectation someone will just magically fix 
> > > it!
> > >
> > > > On Mon, Feb 3, 2020 at 8:21 AM Erick Erickson  
> > > > wrote:
> > > > > +1 to option A.
> > > > >
> > > > > We can also remove the “fix version” whenever we notice it entered 
> > > > > prematurely. There’ll still be some that sneak through, but between 
> > > > > removing it from the create screen and fixing it when we notice, 
> > > > > there’ll be many fewer next time. Which is good enough.
> > > > >
> > > > > Yeah, using “blocker” is iffy the more I think about it, I don’t have 
> > > > > much of an opinion either way. It’s either “learn to ignore blockers 
> > > > > that are for a future version” or “look at everything that’s marked 
> > > > > for the version you’re releasing and is still open”. If we tighten up 
> > > > > the “fix version”, the second requires less effort….
> > > > >
> > > > >
> > > > > > On Feb 3, 2020, at 7:57 AM, Jason Gerlowski  
> > > > > > wrote:
> > > > > >
> > > > > > +1 on Option A.
> > > > > >
> > > > > > [-0] on Option B.  Even though it might not be everyday, I don't 
> > > > > > think
> > > > > > we should put roadblocks in front of users who want to clean up 
> > > > > > after
> > > > > > themselves.  We do occasionally see users create jira issues and 
> > > > > > then
> > > > > > close them themselves when they realize user error or something else
> > > > > > was at play.
> > > > > >
> > > > > > On Mon, Feb 3, 2020 at 12:03 AM David Smiley 
> > > > > >  wrote:
> > > > > >>
> > > > > >> I think too often a "Fix Version" is set prematurely, especially 
> > > > > >> by contributors who don't know better and seem to choose arbitrary 
> > > > > >> values, thus making this JIRA field less meaningful.  Ideally it 
> > > > > >> is set on resolution.  We've also used it to assign issues to 
> > > > > >> releases in advance to avoid forgetting about them.[1] The 
> > > > > >> permissions on this field in JIRA appears to be a bit unique[2]; 
> > > > > >> it's tied to the ability to "Resolve" issues.  Reporters (who 
> > > > > >> could be anybody) can resolve issues (e.g. to close) can thus set 
> > > > > >> the fix version.  I can see a couple options to improve the 
> > > > > >> situation *and we could do both*.  I propose we do both in fact.
> > > > > >>
> > > > > >> Option A:  Remove "Fix Version" from the "create issue" screen.
> > > > > >> If usually this shouldn't be set on issue creation, then let's 
> > > > > >> remove the temptation to set it here.  Many contributors, I think, 
> > > > > >> only ever see the create-issue screen and won't edit the issue, 
> > > > > >> which we'll leave open for the ability to set this field.  
> > > > > >> Implementing this appears easy as we've got our own 
> > > > > >> project-specific screen to manipulate.
> > > > > >>
> > > > > >> Option B:  Revoke the "Resolve" permission for the Reporter.
> > > > > >> It seems unusual for simple contributors to "Resolve" the issue.  
> > > > > >> They might note it's a duplicate after-the-fact but it seems quite 
> > > > > >> rare to me; it's usually us committers (who retain the right to 
> > > > > >> Resolve any issue) who point out a duplicate or perhaps decide the 
> > > > > >> issue is a "Won't-Fix" or whatever.  Implementing this proposal 
> > > > > >> would require moving to a project-specific permission scheme 
> > > > > >> instead of using the default one that's in use by 349 projects.
> > > > > >>
> > > > > >> [1]: We might stop the practice of using fix-version as a TODO for 
> > > > > >> unresolved issues, and thus fix-version would simply only ever get 
> > > > > >> set for resolved issues and thus be editable on a resolution 
> > > > > >> screen.  But what other approach?  Maybe Priority of Blocker, 
> > > > > >> though it wouldn't differentiate the next-major release from the 
> > > > > >> next-minor one.  Shrug; the status quo 

Re: Solr 9.0?

[Cassandra Targett]

Our Jira is connected to Confluence and supports some pretty nice integration 
features. Instead of trying to organize 100s of issues in Jira, we could make a 
"9.0 Planning" page in Confluence and use that integration to show us issue 
status along our primary goals.

This integration is primarily driven from queries of Jira, so instead of a page 
that’s a huge list of issues, we could use a combination of the Fix Version 
field and labels (or any other combination of query-able data elements) to make 
queries, charts, and/or reports for each goal we intend to try to accomplish.

For example, if we want “Improve SolrCloud stability” to be something we 
achieve before the release, we identify the Jira issues that define how we plan 
to meet that goal and make a query for them. Then we set up a section of the 
9.0 Planning page to show the progress (either a list of issues, or a chart, or 
both). Then every time anyone wants to know where we’re at, we just go to the 
page and the status is automatically updated. If we’re not making progress on a 
goal, we can choose to defer it or any of the issues in it (change the fix 
version/label) at any time and the page stays up to date with our current plan.

More info on the integration points: 
https://confluence.atlassian.com/conf71/use-jira-applications-and-confluence-together-979423628.html

Since the cwiki spaces are separated between Lucene and Solr, we could have 2 
pages for this planning that link to each other (if we want).

Just a suggestion, but I think users who like to try to plan for new major 
versions would love to see what we’re planning in an easier way, and I think it 
would really help us stay organized.

Cassandra
On Feb 3, 2020, 7:24 AM -0600, David Smiley , wrote:
> I suspect your motivation for something other than a JIRA query is that 
> developing a JIRA query can take a few minutes whereas a simple tag to search 
> is less.  But just a tag is less powerful and is, I think, redundant with the 
> existing JIRA metadata.  Tags need to be maintained; if we do a simply tag 
> this release then we need to clean them up after release since it'd get in 
> the way at a subsequent release.  And think of it this way: many of us have 
> already been in effect curating our TODO for 9.x list using fix-version.
>
> This JIRA query matches 54 issues.  I edited the previous query to list only 
> issues that are either assigned or that are priority of Blocker:
>
> https://issues.apache.org/jira/issues/?jql=project%20in%20(LUCENE%2C%20SOLR)%20AND%20fixVersion%20%3D%20%22master%20(9.0)%22%20AND%20resolution%20is%20EMPTY%20and%20(assignee%20is%20not%20EMPTY%20OR%20priority%20%3D%20Blocker)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Feel free to just refer back to this email to click this link so that you 
> needn't waste time writing a JIRA query.  In addition, maybe we could make 
> this easier in a release "developer docs" page.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> > On Mon, Feb 3, 2020 at 7:38 AM Erick Erickson  
> > wrote:
> > > bq. it seems like a huge misuse of JIRA
> > >
> > > I disagree, but not enough to bikeshed. I’m looking for the most 
> > > efficient way to get the scope of what we want to include in 9.0 defined.
> > >
> > > Wading through 134 issues is tedious, WDYT about a “future” tag? Once we 
> > > go through those 134 issues and change the ones we know we won’t get to 
> > > the process will be more tractable. We could make the ones we want to 
> > > include in 9.0 “blockers”.
> > >
> > > Point is mostly to get a way to measure progress. The last thing I want 
> > > to do is wade through 134 issues making a judgement call on each one 
> > > multiple times between now and release.
> > >
> > >
> > >
> > > > On Feb 2, 2020, at 4:48 PM, David Smiley  
> > > > wrote:
> > > >
> > > > We can use JIRA to annotate what we want to do for 9x.  I know from 
> > > > experience it can be a bit aspirational and that's okay.  Eventually 
> > > > reality will set in and we'll remove the fix-version accordingly.
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley
> > > >
> > > >
> > > > On Sun, Feb 2, 2020 at 4:46 PM Adrien Grand  wrote:
> > > > One Lucene issue I'd like to have in 9.0 is 
> > > > https://issues.apache.org/jira/browse/LUCENE-9047, which is about 
> > > > making our directory abstractions little-endian instead of big-endian. 
> > > > It would be breaking enough that it should be done in a major.
> > > >
> > > > On Sun, Feb 2, 2020 at 3:35 PM Erick Erickson  
> > > > wrote:
> > > > What are people’s thoughts about Solr 9.0? It’d be a little faster than 
> > > > our recent cadence, the last two major releases were about 18 months 
> > > > after the one before and we released Solr 8.0 last March.
> > > >
> > > > Besides the usual reasons, there are two drivers I can think of:
> > > >
> > > > 1> 

Congratulations to the new Lucene/Solr PMC Chair, Anshum Gupta!

[Cassandra Targett]

Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
President position.

This year we have nominated and elected Anshum Gupta as the Chair, a
decision that the board approved in its January 2020 meeting.

Congratulations, Anshum!

Cassandra

Re: Lucene/Solr Developer content

[Cassandra Targett]

Shoot, the issue is SOLR-12930, not what I wrote 
earlier...https://issues.apache.org/jira/browse/SOLR-12930
On Jan 13, 2020, 3:25 PM -0600, Cassandra Targett , 
wrote:
> I’m hoping to resurrect this - I didn’t have time to help out with this last 
> Summer, but I’m hoping I have some time now. There was an earlier 
> conversation about what to do with developer docs back in Oct 2018, so I’ve 
> also updated SOLR-12940 to use for creating the developer doc structure and 
> getting moving forward with this.
>
> I wrote some docs for how the PMC Chair does the stuff they need to do, so 
> I’ll create a PR today that we can use for discussion about how we want to 
> move forward.
> On Aug 16, 2019, 10:41 AM -0500, Jan Høydahl , wrote:
> > Continuing the discussion about our new dev-docs. Seems to be consensus of 
> > using Asciidoc.
> >
> > I proposed three separate guides:
> >
> > > * /dev-docs : Common info i.e. Git, Pull requests, building, doing 
> > > releases etc. Publish in TLP site
> > > * /lucene/dev-guide : Lucene-specific developer content. Publish in 
> > > Lucene web site
> > > * /solr/dev-guide : Solr-specific developer content. Publish in Solr web 
> > > site
> >
> > It is obvious that Lucene and Solr needs separate guides, but could we 
> > instead of adding a third TLP guide use asciidoc  for a few common 
> > .adoc in both the Lucene and Solr guides to avoid duplication?
> >
> > Don't yet know how the adoc -> html build would look like, there are 
> > several such tools out there and it is not given that we need to use the 
> > same tool as we do for the Solr RefGuide? Any thoughts?
> >
> > If we can conclude on the framework we could create JIRAs and start adding 
> > the skeleton…
> > I also hope we can get some assistance from a Technical Writer in 
> > organizing the content, so we don't end up with one huge page or a random 
> > structure.
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> > > 17. jun. 2019 kl. 22:17 skrev Jan Høydahl :
> > >
> > > Hi devs,
> > >
> > > Today we have mainly two sources of developer documentation (apart from 
> > > Javadoc and refGuide):
> > >
> > > * The websites. Very short instructions and linking to WIKI for in-depth
> > > * The old Moin wikis at wiki.apache.org with more details
> > >
> > > Soon the old Moin wiki is being discontinued and I plan to migrate that 
> > > content to Confluence this week, see 
> > > https://issues.apache.org/jira/browse/LUCENE-8858 and 
> > > https://issues.apache.org/jira/browse/SOLR-13548
> > >
> > > So the first step will be to just start using Confluence instead of Moin. 
> > > Help appreciated with the cleanup once the first migration is done in the 
> > > two JIRAs above. A LOT of the content in old WIKIs is outdated and a big 
> > > cleanup once this is in Confluence is highly needed!
> > >
> > >
> > > Someone has also suggested to move most developer resources found in the 
> > > WIKI into the main GIT code tree, so you have it right there with your 
> > > git clone. What I want to discuss here is more detailed how that would 
> > > look like and what info to move over.
> > >
> > > One idea is to create one or more Asciidoc guides in the source tree, e.g
> > >
> > > * /dev-docs : Common info i.e. Git, Pull requests, building, doing 
> > > releases etc. Publish in TLP site
> > > * /lucene/dev-guide : Lucene-specific developer content. Publish in 
> > > Lucene web site
> > > * /solr/dev-guide : Solr-specific developer content. Publish in Solr web 
> > > site
> > >
> > > These will be built with Jekyll by Jenkins, into nice HTML guides and 
> > > published to the web sites.
> > >
> > > There may be other ways to do this as well, such as creating a new git 
> > > repo for dev docs, but I think people have good experience from Solr's 
> > > ref-guide with keeping code and docs in sync. What do you think?
> > >
> > > --
> > > Jan Høydahl, search solution architect
> > > Cominvent AS - www.cominvent.com
> > >
> >

Re: Lucene/Solr Developer content

[Cassandra Targett]

I’m hoping to resurrect this - I didn’t have time to help out with this last 
Summer, but I’m hoping I have some time now. There was an earlier conversation 
about what to do with developer docs back in Oct 2018, so I’ve also updated 
SOLR-12940 to use for creating the developer doc structure and getting moving 
forward with this.

I wrote some docs for how the PMC Chair does the stuff they need to do, so I’ll 
create a PR today that we can use for discussion about how we want to move 
forward.
On Aug 16, 2019, 10:41 AM -0500, Jan Høydahl , wrote:
> Continuing the discussion about our new dev-docs. Seems to be consensus of 
> using Asciidoc.
>
> I proposed three separate guides:
>
> > * /dev-docs : Common info i.e. Git, Pull requests, building, doing releases 
> > etc. Publish in TLP site
> > * /lucene/dev-guide : Lucene-specific developer content. Publish in Lucene 
> > web site
> > * /solr/dev-guide : Solr-specific developer content. Publish in Solr web 
> > site
>
> It is obvious that Lucene and Solr needs separate guides, but could we 
> instead of adding a third TLP guide use asciidoc  for a few common 
> .adoc in both the Lucene and Solr guides to avoid duplication?
>
> Don't yet know how the adoc -> html build would look like, there are several 
> such tools out there and it is not given that we need to use the same tool as 
> we do for the Solr RefGuide? Any thoughts?
>
> If we can conclude on the framework we could create JIRAs and start adding 
> the skeleton…
> I also hope we can get some assistance from a Technical Writer in organizing 
> the content, so we don't end up with one huge page or a random structure.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 17. jun. 2019 kl. 22:17 skrev Jan Høydahl :
> >
> > Hi devs,
> >
> > Today we have mainly two sources of developer documentation (apart from 
> > Javadoc and refGuide):
> >
> > * The websites. Very short instructions and linking to WIKI for in-depth
> > * The old Moin wikis at wiki.apache.org with more details
> >
> > Soon the old Moin wiki is being discontinued and I plan to migrate that 
> > content to Confluence this week, see 
> > https://issues.apache.org/jira/browse/LUCENE-8858 and 
> > https://issues.apache.org/jira/browse/SOLR-13548
> >
> > So the first step will be to just start using Confluence instead of Moin. 
> > Help appreciated with the cleanup once the first migration is done in the 
> > two JIRAs above. A LOT of the content in old WIKIs is outdated and a big 
> > cleanup once this is in Confluence is highly needed!
> >
> >
> > Someone has also suggested to move most developer resources found in the 
> > WIKI into the main GIT code tree, so you have it right there with your git 
> > clone. What I want to discuss here is more detailed how that would look 
> > like and what info to move over.
> >
> > One idea is to create one or more Asciidoc guides in the source tree, e.g
> >
> > * /dev-docs : Common info i.e. Git, Pull requests, building, doing releases 
> > etc. Publish in TLP site
> > * /lucene/dev-guide : Lucene-specific developer content. Publish in Lucene 
> > web site
> > * /solr/dev-guide : Solr-specific developer content. Publish in Solr web 
> > site
> >
> > These will be built with Jekyll by Jenkins, into nice HTML guides and 
> > published to the web sites.
> >
> > There may be other ways to do this as well, such as creating a new git repo 
> > for dev docs, but I think people have good experience from Solr's ref-guide 
> > with keeping code and docs in sync. What do you think?
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
>

Re: [JENKINS] Solr-reference-guide-master - Build # 21311 - Still Failing

[Cassandra Targett]

The rvm.io certificate issue has been resolved, so I’ve re-enabled the regular 
Ref Guide Jenkins jobs for master and branch_8x. Both are passing again.

I left the branch_8_4 job disabled since the final Guide was published earlier 
this week; I’ll remove it in a few days.

Cassandra
On Dec 30, 2019, 9:27 AM -0600, Cassandra Targett , 
wrote:
> These Ref Guide build failures are happening because apparently the rvm.io 
> domain got parked when the certificate expired (today), and we use it to 
> download the Ruby gems the build needs.
>
> The maintainer is working on it 
> (https://twitter.com/mpapis/status/1211657656676618241) but it’s not clear 
> when it will all get resolved. I’ll disable these jobs for now until it 
> settles out.
>
> Cassandra
> On Dec 30, 2019, 9:02 AM -0600, Apache Jenkins Server 
> , wrote:
> > Build: https://builds.apache.org/job/Solr-reference-guide-master/21311/
> >
> > Log:
> > Started by timer
> > Running as SYSTEM
> > [EnvInject] - Loading node environment variables.
> > Building remotely on websites (git-websites svn-websites) in workspace 
> > /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> > No credentials specified
> > > git rev-parse --is-inside-work-tree # timeout=10
> > Fetching changes from the remote Git repository
> > > git config remote.origin.url 
> > > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
> > Cleaning workspace
> > > git rev-parse --verify HEAD # timeout=10
> > Resetting working tree
> > > git reset --hard # timeout=10
> > > git clean -fdx # timeout=10
> > Fetching upstream changes from 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git
> > > git --version # timeout=10
> > > git fetch --tags --progress -- 
> > > https://gitbox.apache.org/repos/asf/lucene-solr.git 
> > > +refs/heads/*:refs/remotes/origin/*
> > > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> > > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> > Checking out Revision 5a50eaa2c683a2921a1e1e846593bda48e36b296 
> > (refs/remotes/origin/master)
> > > git config core.sparsecheckout # timeout=10
> > > git checkout -f 5a50eaa2c683a2921a1e1e846593bda48e36b296
> > Commit message: "Word choice should be starting, not staring (#1128)"
> > > git rev-list --no-walk 5a50eaa2c683a2921a1e1e846593bda48e36b296 # 
> > > timeout=10
> > No emails were triggered.
> > [Solr-reference-guide-master] $ /bin/bash -xe 
> > /tmp/jenkins1629544295672754616.sh
> > + bash dev-tools/scripts/jenkins.build.ref.guide.sh
> > + set -e
> > + RVM_PATH=/home/jenkins/.rvm
> > + RUBY_VERSION=ruby-2.5.1
> > + GEMSET=solr-refguide-gemset
> > + curl -sSL https://get.rvm.io
> > + bash -s -- --ignore-dotfiles stable
> > bash: line 1: syntax error near unexpected token `<'
> > bash: line 1: ` > data-adblockkey=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANnylWw2vLY4hUn9w06zQKbhKBfvjFUCsdFlb6TdQhxb9RXWXuI4t31c+o8fYOv/s8q1LGPga3DE1L/tHU4LENMCAwEAAQ==_adhoxtRcrXAWywYiNYiuVE5HzTz/n+3YP2Qc18oS6WsWTma6cJWK5TDzpKzajIYKMPKwJ4QdOrvgotw84dbD1Q==> >  charset="utf-8" />/*!normalize.css v1.1.2 | MIT 
> > License | git.io/normalize */ 
> > article,aside,details,figcaption,figure,footer,header,hgroup,main,nav,section,summary{display:block;}audio,canvas,video{display:inline-block;*display:inline;*zoom:1;}audio:not([controls]){display:none;height:0;}[hidden]{display:none;}html{font-size:100%;-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%;}html,button,input,select,textarea{font-family:sans-serif;}body{margin:0;}a:focus{outline:thin
> >  
> > dotted;}a:active,a:hover{outline:0;}h1{font-size:2em;margin:0;}h2{font-size:1.33em;margin:0;}h3{font-size:1.1em;margin:0;}h4{font-size:1em;margin:0;}h5{font-size:.83em;margin:0;}h6{font-size:.67em;margin:0;}abbr[title]{border-bottom:1px
> >  dotted;}b,strong{font-weight:bold;}blockquote{margin:.11em 
> > 40px;}dfn{font-style:italic;}hr{-moz-box-sizing:content-box;box-sizing:content-box;height:0;}mark{background:#FF0;color:#000;}p,pre{margin:.11em
> >  0;}code,kbd,pre,samp{font-family:monospace,serif;_font-family:'courier 
> > new',monospace;font-size:1em;}pre{white-space:pre;white-space:pre-wrap;word-wrap:break-word;}q{quotes:none;}q:before,q:after{content:'';content:none;}small{font-size:80%;}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline;}sup{top:-0.5em;}sub{bottom:-0.25em;}dl,menu,ol,ul{margin:0;}dd{margin:0
> >  0 0 40px;}menu,ol,ul{padding:0;list-style:none;}nav ul,nav 
> > ol{list-style:none;list-style-image:none;}img{border:0;-ms-interpolation-mode

Re: [JENKINS] Solr-reference-guide-master - Build # 21311 - Still Failing

[Cassandra Targett]

These Ref Guide build failures are happening because apparently the rvm.io 
domain got parked when the certificate expired (today), and we use it to 
download the Ruby gems the build needs.

The maintainer is working on it 
(https://twitter.com/mpapis/status/1211657656676618241) but it’s not clear when 
it will all get resolved. I’ll disable these jobs for now until it settles out.

Cassandra
On Dec 30, 2019, 9:02 AM -0600, Apache Jenkins Server 
, wrote:
> Build: https://builds.apache.org/job/Solr-reference-guide-master/21311/
>
> Log:
> Started by timer
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> Building remotely on websites (git-websites svn-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> No credentials specified
> > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
> > git config remote.origin.url 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
> Cleaning workspace
> > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
> > git reset --hard # timeout=10
> > git clean -fdx # timeout=10
> Fetching upstream changes from 
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> > git --version # timeout=10
> > git fetch --tags --progress -- 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git 
> > +refs/heads/*:refs/remotes/origin/*
> > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 5a50eaa2c683a2921a1e1e846593bda48e36b296 
> (refs/remotes/origin/master)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f 5a50eaa2c683a2921a1e1e846593bda48e36b296
> Commit message: "Word choice should be starting, not staring (#1128)"
> > git rev-list --no-walk 5a50eaa2c683a2921a1e1e846593bda48e36b296 # timeout=10
> No emails were triggered.
> [Solr-reference-guide-master] $ /bin/bash -xe 
> /tmp/jenkins1629544295672754616.sh
> + bash dev-tools/scripts/jenkins.build.ref.guide.sh
> + set -e
> + RVM_PATH=/home/jenkins/.rvm
> + RUBY_VERSION=ruby-2.5.1
> + GEMSET=solr-refguide-gemset
> + curl -sSL https://get.rvm.io
> + bash -s -- --ignore-dotfiles stable
> bash: line 1: syntax error near unexpected token `<'
> bash: line 1: ` data-adblockkey=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANnylWw2vLY4hUn9w06zQKbhKBfvjFUCsdFlb6TdQhxb9RXWXuI4t31c+o8fYOv/s8q1LGPga3DE1L/tHU4LENMCAwEAAQ==_adhoxtRcrXAWywYiNYiuVE5HzTz/n+3YP2Qc18oS6WsWTma6cJWK5TDzpKzajIYKMPKwJ4QdOrvgotw84dbD1Q==>  charset="utf-8" />/*!normalize.css v1.1.2 | MIT 
> License | git.io/normalize */ 
> article,aside,details,figcaption,figure,footer,header,hgroup,main,nav,section,summary{display:block;}audio,canvas,video{display:inline-block;*display:inline;*zoom:1;}audio:not([controls]){display:none;height:0;}[hidden]{display:none;}html{font-size:100%;-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%;}html,button,input,select,textarea{font-family:sans-serif;}body{margin:0;}a:focus{outline:thin
>  
> dotted;}a:active,a:hover{outline:0;}h1{font-size:2em;margin:0;}h2{font-size:1.33em;margin:0;}h3{font-size:1.1em;margin:0;}h4{font-size:1em;margin:0;}h5{font-size:.83em;margin:0;}h6{font-size:.67em;margin:0;}abbr[title]{border-bottom:1px
>  dotted;}b,strong{font-weight:bold;}blockquote{margin:.11em 
> 40px;}dfn{font-style:italic;}hr{-moz-box-sizing:content-box;box-sizing:content-box;height:0;}mark{background:#FF0;color:#000;}p,pre{margin:.11em
>  0;}code,kbd,pre,samp{font-family:monospace,serif;_font-family:'courier 
> new',monospace;font-size:1em;}pre{white-space:pre;white-space:pre-wrap;word-wrap:break-word;}q{quotes:none;}q:before,q:after{content:'';content:none;}small{font-size:80%;}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline;}sup{top:-0.5em;}sub{bottom:-0.25em;}dl,menu,ol,ul{margin:0;}dd{margin:0
>  0 0 40px;}menu,ol,ul{padding:0;list-style:none;}nav ul,nav 
> ol{list-style:none;list-style-image:none;}img{border:0;-ms-interpolation-mode:bicubic;}svg:not(:root){overflow:hidden;}figure{margin:0;}form{margin:0;}fieldset{border:0
>  
> none;margin:0;padding:0;}legend{border:0;padding:0;white-space:normal;*margin-left:-7px;}button,input,select,textarea{font-size:100%;margin:0;vertical-align:middle;*vertical-align:middle;}button,input{line-height:normal;}button,select{text-transform:none;}button,html
>  
> input[type="button"],input[type="reset"],input[type="submit"]{-webkit-appearance:button;cursor:pointer;*overflow:visible;}button[disabled],html
>  
> 

Re: Propose eliminate "Versions of Major Components"

[Cassandra Targett]

+1 to removing from CHANGES.txt, but I think we should really try to publish 
them somewhere instead of asking people to look for .jars.

If we were to go the way I’ve been advocating to go - to have a single page in 
the Ref Guide for each release that includes the new features + upgrade notes 
in a single place instead of two - it would be really trivial to publish the 
versions for the major components on the same page. Most of them already exist 
as Guide build parameters already, a single place would make it less likely 
they're broken for 2 releases (thanks Jan for fixing that), and it is very 
little effort to add new ones as needed.

Cassandra
On Dec 24, 2019, 8:37 AM -0600, Erick Erickson , wrote:
> I started out strongly negative on this, since the idea of just looking at 
> the jar file names presupposed you know _where_ to look in the first place.
>
> Then realized jar files are a mess, just ask Dawid. There are 272 jar files 
> in the 8.3 distro, scattered all over the place. This may get better when we 
> move to Gradle, but even then there will still be a lot of jar files.
>
> For instance, there are three copies of slf4j-api-1.7.24.jar in the distro, 
> which one is important? At least they all have the same version so that’s 
> something.
>
> ./dist/solrj-lib/slf4j-api-1.7.24.jar
> ./server/lib/ext/slf4j-api-1.7.24.jar
> ./contrib/prometheus-exporter/lib/slf4j-api-1.7.24.jar
>
> Zookeeper is in ./dist/solrj-lib/ and 
> ./server/solr-webapp/webapp/WEB-INF/lib/. Which one is important? Which one 
> is used? Which one should I use if I want to run an external Zookeeper? 
> Gah.
>
> So the more I thought about it, the more I realized it’s just impossible to 
> untangle that in the CHANGES.txt file, and the point of specifying which Tika 
> version is well taken (why that and not others?). The only component that I 
> think _shouldn’t_ be something a user needs to dig for is Zookeeper since we 
> recommend that they install an external ensemble. And just putting Zookeeper 
> in CHANGES.txt is awkward.
>
> For that matter, why to we specify the JVM in a different place in 
> CHANGES.txt? That should be moved to a system-requirements page too IMO. I’d 
> frankly rather go find the one place the relevant information is than 
> reconcile multiple, possibly conflicting sources.
>
> So after dithering for far too long, +1 to rip this out of CHANGES.txt. We 
> should take the JVM out of CHANGES.txt too. Let’s put this in a system 
> requirements page in the ref guide and point to it from CHANGES.txt. I think 
> we should just point here: https://lucene.apache.org/solr/guide/ which lets 
> them pick the version of the ref guide rather than to a specific version on 
> the theory that it’s one less thing to keep synchronized. Perhaps guiding 
> them to look at “System requirements>>Solr System Requirements”. (and, BTW, I 
> love “Solr System Requirements”, when I was working on the page I wanted to 
> start with “start a few billion yeas ago with a lot of interstellar dust and 
> gas and...”).
>
> > On Dec 24, 2019, at 6:56 AM, Jan Høydahl  wrote:
> >
> > Jetty version is printed early in the logs so should be easy to find if you 
> > don’t want to check the sources.
> >
> > Looking in RefGuide for ZK version, there seems to be a bug, see 
> > https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper
> > The variable ${org.apache.zookeeper.version} is not expanded in the 
> > asciidoc… I opened https://issues.apache.org/jira/browse/SOLR-14146
> >
> > Jan
> >
> > > 24. des. 2019 kl. 06:48 skrev David Smiley :
> > >
> > > +1 to all that Jan; your response was very thoughtful.
> > >
> > > Except "Perhaps just keep Jetty version in CHANGES". Why? Since the WAR 
> > > option went away, we now think of Jetty as a component of Solr instead of 
> > > something we deploy to, at least in communication to our users. If an 
> > > advanced user wants to mess with Jetty configuration, I'm sure he/she 
> > > will figure it out.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Mon, Dec 23, 2019 at 5:59 PM Jan Høydahl  wrote:
> > > In the binary distro there is no version.properties...
> > >
> > > Perhaps just keep Jetty version in CHANGES?
> > > The Zookeeper version is useful if you want to choose an external ZK to 
> > > install, but the refGuide should help here.
> > > Unfortunately we do not link to the Reference Guide from README in Solr 
> > > binary download so that info is not readily available either.
> > > I think we should link to online ref-guide both from README and from 
> > > online docs https://lucene.apache.org/solr/8_2_0/
> > > Also, recommended ZK version for Cloud should be part of 
> > > SYSTEM_REQUIREMENTS.txt, i.e. 
> > > https://lucene.apache.org/solr/8_2_0/SYSTEM_REQUIREMENTS.html ?
> > >
> > > Jan
> > >
> > > > 23. des. 2019 kl. 22:49 skrev 

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Cassandra Targett]

A little late for some votes, but the Draft version of the 8.4 Solr Ref Guide 
is up now: https://lucene.apache.org/solr/guide/8_4/

(I need to get on automating it soon.)
On Dec 18, 2019, 8:52 AM -0600, Gus Heck , wrote:
> Hi Mkhail, This is a known flakey test (mine, it's on my to do list). Seems 
> to have got slightly more flakey recently possibly because other tests have 
> got better at using up CPU?. The flake here is that the code in the test 
> didn't manage to wait long enough before running the assertion. This failure 
> does not represent an issue with anything other than the test.
>
> > On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  wrote:
> > > I've got
> > >   2> NOTE: reproduce with: ant test  
> > > -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest 
> > > -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B 
> > > -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
> > > ests.asserts=true -Dtests.file.encoding=ISO-8859-1
> > > [00:42:59.083] FAILURE 29.4s J1 | 
> > > DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
> > >    > Throwable #1: java.lang.AssertionError: expected:<10> but was:<9>
> > >    >    at 
> > > __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
> > >    >    at org.junit.Assert.fail(Assert.java:88)
> > >    >    at org.junit.Assert.failNotEquals(Assert.java:834)
> > >    >    at org.junit.Assert.assertEquals(Assert.java:645)
> > >    >    at org.junit.Assert.assertEquals(Assert.java:631)
> > >    >    at 
> > > org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
> > >    >    at 
> > > org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
> > >
> > > > which didn't reproduce to me when I retry.
> > > >
> > > > +0
> > > >
> > > > On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  wrote:
> > > > > Please vote for release candidate 1 for Lucene/Solr 8.4.0
> > > > >
> > > > > The artifacts can be downloaded from:
> > > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > > > >
> > > > > You can run the smoke tester directly with this command:
> > > > >
> > > > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > > > >
> > > > > The vote will be open for at least 3 working days, i.e. until 
> > > > > 2019-12-20 19:00 UTC.
> > > > >
> > > > > [ ] +1  approve
> > > > > [ ] +0  no opinion
> > > > > [ ] -1  disapprove (and reason why)
> > > > >
> > > > > Here is my +1
> > > > >
> > > > > --
> > > > > Adrien
> > >
> > >
> > > --
> > > Sincerely yours
> > > Mikhail Khludnev
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

Re: New branch and feature freeze for Lucene/Solr 8.4.0

[Cassandra Targett]

I’m going to have a few commits coming in to branch_8_4 today for the Ref Guide 
- I’m assuming as usual it’s OK for me to go ahead but if you want me to hold 
for a short time while you’re building or whatever, I will.
On Dec 16, 2019, 9:35 AM -0600, Adrien Grand , wrote:
> Awesome, thanks Ishan.
>
> > On Mon, Dec 16, 2019 at 4:14 PM Ishan Chattopadhyaya 
> >  wrote:
> > > Adrien, I've pushed a fix for that issue. The failure was probably due
> > > to usual flakiness, but hopefully you won't see the exception for that
> > > test that Dawid reported.
> > > I don't think it should be a blocker anymore (the other problem is
> > > that a test is trying to write data to source tree; I think that can
> > > be solved later).
> > >
> > > On Mon, Dec 16, 2019 at 8:42 PM Adrien Grand  wrote:
> > > >
> > > > Could someone look at https://issues.apache.org/jira/browse/SOLR-14096 
> > > > which Dawid just opened? It looks to me like it should be a blocker?
> > > >
> > > > On Mon, Dec 16, 2019 at 1:55 PM Adrien Grand  wrote:
> > > >>
> > > >> I have to rebuild because of SOLR-14094, so I'll include SOLR-14087 
> > > >> too.
> > > >>
> > > >> On Mon, Dec 16, 2019 at 1:52 PM Ishan Chattopadhyaya 
> > > >>  wrote:
> > > >>>
> > > >>> Hi Adrien,
> > > >>> I reverted one of the changes in SOLR-14087, and backported to 8.4
> > > >>> branch. Apologies for the last moment change.
> > > >>> If RC1 goes out without this change, no worries and we'll deal with 
> > > >>> it later.
> > > >>> Thanks and regards,
> > > >>> Ishan
> > > >>>
> > > >>> On Mon, Dec 16, 2019 at 3:50 PM Ishan Chattopadhyaya
> > > >>>  wrote:
> > > >>> >
> > > >>> > Hi Adrien,
> > > >>> > Let's push it to 8.5.
> > > >>> > +1 to proceed for RC1.
> > > >>> > Thanks,
> > > >>> > Ishan
> > > >>> >
> > > >>> > On Mon, 16 Dec, 2019, 2:07 PM Adrien Grand,  
> > > >>> > wrote:
> > > >>> >>
> > > >>> >> Among the various JIRAs mentioned above, it looks like only 
> > > >>> >> https://issues.apache.org/jira/browse/SOLR-14066 is not in yet. 
> > > >>> >> Please let me know if there are other JIRAs that you are thinking 
> > > >>> >> of getting it that have not been pushed yet, but in general I'd 
> > > >>> >> like to start pushing changes to 8.5 whenever possible to avoid 
> > > >>> >> delaying the release too much.
> > > >>> >>
> > > >>> >> On Sun, Dec 15, 2019 at 1:17 PM Noble Paul  
> > > >>> >> wrote:
> > > >>> >>>
> > > >>> >>> I plan to commit the following as well.
> > > >>> >>> It's just a precautionery measure to avoid any future exploits
> > > >>> >>> https://github.com/apache/lucene-solr/pull/1085
> > > >>> >>>
> > > >>> >>> On Sun, Dec 15, 2019 at 4:32 PM Ishan Chattopadhyaya
> > > >>> >>>  wrote:
> > > >>> >>> >
> > > >>> >>> > I've added a few critical fixes for SOLR-13662 to the branch. I 
> > > >>> >>> > tested
> > > >>> >>> > them thoroughly and got reviews for the fixes from Jan, Noble 
> > > >>> >>> > and
> > > >>> >>> > Eduardo.
> > > >>> >>> >
> > > >>> >>> > On Sun, Dec 15, 2019 at 5:18 AM Adrien Grand 
> > > >>> >>> >  wrote:
> > > >>> >>> > >
> > > >>> >>> > > Hi Kevin,
> > > >>> >>> > >
> > > >>> >>> > > I'll defer to your judgement regarding whether this is safe 
> > > >>> >>> > > to get in 8.4.
> > > >>> >>> > >
> > > >>> >>> > > Le sam. 14 déc. 2019 à 21:00, Kevin Risden 
> > > >>> >>> > >  a écrit :
> > > >>> >>> > >>
> > > >>> >>> > >> Tim found SOLR-14086 which looks like a test only dependency 
> > > >>> >>> > >> leaking into compile caused by SOLR-14033. I put a patch up. 
> > > >>> >>> > >> I won't get to get it until later tonight or tomorrow ~24hrs 
> > > >>> >>> > >> from now.
> > > >>> >>> > >>
> > > >>> >>> > >> This causes any Solr Tika usage with 7z or a few other 
> > > >>> >>> > >> compressed file types (depends if they use commons-compress) 
> > > >>> >>> > >> to fail due to different classloaders being used.
> > > >>> >>> > >>
> > > >>> >>> > >> Kevin Risden
> > > >>> >>> > >>
> > > >>> >>> > >>
> > > >>> >>> > >> On Sat, Dec 14, 2019 at 2:09 PM Jan Høydahl 
> > > >>> >>> > >>  wrote:
> > > >>> >>> > >>>
> > > >>> >>> > >>> Deprecation of DIH is ready for review 
> > > >>> >>> > >>> https://issues.apache.org/jira/browse/SOLR-14066
> > > >>> >>> > >>> One code change which is a WARN log at startup, other 
> > > >>> >>> > >>> changes are documentation.
> > > >>> >>> > >>>
> > > >>> >>> > >>> Low risk and we’d like to deprecate sooner rather than 
> > > >>> >>> > >>> later in 8.x. Your call Adrien.
> > > >>> >>> > >>>
> > > >>> >>> > >>> Jan
> > > >>> >>> > >>>
> > > >>> >>> > >>> 13. des. 2019 kl. 10:03 skrev Adrien Grand 
> > > >>> >>> > >>> :
> > > >>> >>> > >>>
> > > >>> >>> > >>> Let's get that one in as well, thanks Yonik.
> > > >>> >>> > >>>
> > > >>> >>> > >>> On Fri, Dec 13, 2019 at 2:26 AM Yonik Seeley 
> > > >>> >>> > >>>  wrote:
> > > >>> >>> > 
> > > >>> >>> >  Heads up on 
> > > >>> >>> >  https://issues.apache.org/jira/browse/SOLR-14079
> > > >>> >>> >  Bad bug (autoscale triggers use async, so 

Re: asciidoctor in gradle build

[Cassandra Targett]

The license .sha file was already updated, the right version just wasn’t in 
that build.gradle. Sorry again for the added noise, merging is messy ;-).

Cassandra
On Nov 13, 2019, 7:47 AM -0600, Cassandra Targett , 
wrote:
> Yes, Erick, that was the cause of the problem Dawid noticed - I just pushed a 
> change to fix it before I saw your mail. I might need to fix the licenses on 
> that branch, but I’ll check that now too.
>
> I’ll confess I don’t think I re-ran the bareBonesHtmlValidation task after 
> I’d made other changes to the Jekyll version, so my fault, sorry for the 
> confusion.
>
> Cassandra
> On Nov 13, 2019, 7:45 AM -0600, Erick Erickson , 
> wrote:
> > Dawid and Cassandra:
> >
> > In the gradle_8 checkout the versions.props file has:
> >
> > org.asciidoctor:asciidoctorj=1.6.0-alpha.5
> >
> > which makes me nervous, so I changed to
> > org.asciidoctor:asciidoctorj=1.6.2
> >
> > in my local checkout. This may be the root of my issues for all I know.
> >
> > Cassandra: this may be relevant to your chasing this down
> >
> > Dawid: Let me try things fresh and we’ll go from there. My changes to the 
> > gradle_8 branch are all about trying to get the dependency versions in 
> > versions.props to match those in ivy-versions.properties since they’re 
> > lagging. Which means changing all the checksum files which.. This cured the 
> > odd problem if me not being able to switch between gradle and ant builds 
> > successfully.
> >
> > WDYT about just checking this in to the gradle_8 branch so we can all 
> > iterate from the same base? Who knows? Maybe whatever makes me “special” 
> > will be obvious.
> >
> > Oh, and now you know why people don’t trust me to make hardware changes ;)
> >
> >
> >
> > > On Nov 13, 2019, at 8:29 AM, Cassandra Targett  
> > > wrote:
> > >
> > > I’ll look into it now.
> > >
> > > Cassandra
> > > On Nov 12, 2019, 4:09 PM -0600, Dawid Weiss , 
> > > wrote:
> > > > Hi Cassandra,
> > > >
> > > > I fixed relative links issue (on jira/SOLR-13452_gradle_8) but there's
> > > > still something odd with asciidoctor -- while the html site generation
> > > > is fine now the validation isn't:
> > > >
> > > > .\gradlew -p solr\solr-ref-guide bareBonesHtmlValidation
> > > >
> > > > it's the same problem as before -- fails on two links with the section
> > > > separator ("-"). I think it's the asciidoctor version problem (like
> > > > before) so maybe we need to upgrade buildScript/ compile dependency
> > > > from 1.6.0-alpha.5 to something else?
> > > >
> > > > Dawid
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >

Re: asciidoctor in gradle build

[Cassandra Targett]

Yes, Erick, that was the cause of the problem Dawid noticed - I just pushed a 
change to fix it before I saw your mail. I might need to fix the licenses on 
that branch, but I’ll check that now too.

I’ll confess I don’t think I re-ran the bareBonesHtmlValidation task after I’d 
made other changes to the Jekyll version, so my fault, sorry for the confusion.

Cassandra
On Nov 13, 2019, 7:45 AM -0600, Erick Erickson , wrote:
> Dawid and Cassandra:
>
> In the gradle_8 checkout the versions.props file has:
>
> org.asciidoctor:asciidoctorj=1.6.0-alpha.5
>
> which makes me nervous, so I changed to
> org.asciidoctor:asciidoctorj=1.6.2
>
> in my local checkout. This may be the root of my issues for all I know.
>
> Cassandra: this may be relevant to your chasing this down
>
> Dawid: Let me try things fresh and we’ll go from there. My changes to the 
> gradle_8 branch are all about trying to get the dependency versions in 
> versions.props to match those in ivy-versions.properties since they’re 
> lagging. Which means changing all the checksum files which.. This cured the 
> odd problem if me not being able to switch between gradle and ant builds 
> successfully.
>
> WDYT about just checking this in to the gradle_8 branch so we can all iterate 
> from the same base? Who knows? Maybe whatever makes me “special” will be 
> obvious.
>
> Oh, and now you know why people don’t trust me to make hardware changes ;)
>
>
>
> > On Nov 13, 2019, at 8:29 AM, Cassandra Targett  
> > wrote:
> >
> > I’ll look into it now.
> >
> > Cassandra
> > On Nov 12, 2019, 4:09 PM -0600, Dawid Weiss , wrote:
> > > Hi Cassandra,
> > >
> > > I fixed relative links issue (on jira/SOLR-13452_gradle_8) but there's
> > > still something odd with asciidoctor -- while the html site generation
> > > is fine now the validation isn't:
> > >
> > > .\gradlew -p solr\solr-ref-guide bareBonesHtmlValidation
> > >
> > > it's the same problem as before -- fails on two links with the section
> > > separator ("-"). I think it's the asciidoctor version problem (like
> > > before) so maybe we need to upgrade buildScript/ compile dependency
> > > from 1.6.0-alpha.5 to something else?
> > >
> > > Dawid
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: asciidoctor in gradle build

[Cassandra Targett]

I’ll look into it now.

Cassandra
On Nov 12, 2019, 4:09 PM -0600, Dawid Weiss , wrote:
> Hi Cassandra,
>
> I fixed relative links issue (on jira/SOLR-13452_gradle_8) but there's
> still something odd with asciidoctor -- while the html site generation
> is fine now the validation isn't:
>
> .\gradlew -p solr\solr-ref-guide bareBonesHtmlValidation
>
> it's the same problem as before -- fails on two links with the section
> separator ("-"). I think it's the asciidoctor version problem (like
> before) so maybe we need to upgrade buildScript/ compile dependency
> from 1.6.0-alpha.5 to something else?
>
> Dawid

Re: Solr Gradle build (SOLR-13452)

[Cassandra Targett]

I was able to get the changes Dawid and I worked out in the gradle_7_refguide 
branch merged into the gradle_8 branch.

There’s one current problem with it, which may be something in my env: in the 
grade_7_refguide branch the HTML files were generated in 
./solr/solr-ref-guide/build, but now they are in the top-level ./build 
directory.

I generally don’t really care where it gets built, but there are a few places 
in the docs where we pull in source code and those now throw an error because 
the path to the files is wrong. If the Ref Guide is going to get built there 
forever, it’s a tiny & simple fix to change the path, I just need to know if 
that’s the plan or if it’s a mistake. This problem also does not need to hold 
up merging that branch to master.

Cassandra
On Nov 11, 2019, 10:54 AM -0600, Erick Erickson , 
wrote:
> I’m trying to push this forward. I intend to keep working on the latest 
> branch of Mark’s Gradle build (jira/SOLR-13452_gradle_8).
>
> This is a plea for anyone interested to at least glance at any updates to 
> that JIRA and chime in if you have any hints. Also, feel free to update that 
> branch yourself as I don’t intend to create another branch, but merge the 
> gradle_8 branch as soon as possible. We can treat it like any other branch 
> that needs work before merging.
>
> I’ll try to keep the gradle_8 branch up to date with master.
>
> I’m concentrating at this point on making the gradle and ant builds play nice 
> together. I saw one situation where after running the Gradle build, “Ant 
> precommit” failed. Turned out to be a mismatch in the versions of some of the 
> jars Solr depends on. What I want people to be able to do is:
>
> > try to use Gradle to do whatever task they need to accomplish. If there’s 
> > no equivalent, then quickly switch to Ant. Or, at worst, execute some 
> > target in Gradle (pristineClean?) to reset to zero and then use Ant.
>
> > get to the minimal point that allows us to merge into master. So far, the 
> > primary objection (private conversation) is that there’s no equivalent of 
> > “ant precommit”. I haven’t checked this out in detail yet.
>
> Also, please feel free to add (or take) sub-tasks of SOLR-13914, where I’m 
> trying to collect an organized list of issues so we can track them.
>
> Best,
> Erick
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: Gradle build

[Cassandra Targett]

I hoped to push my Ref Guide changes to the gradle_8 branch yesterday but got 
distracted with some other stuff for work. I don’t expect I’ll have time to 
work on it this weekend so if you push the other bits to master this weekend, 
I’ll make a new branch off master and will hopefully be able to get it in 
quickly early next week (I’m traveling Tuesday-Friday, so we’ll see).

Cassandra
On Nov 9, 2019, 9:41 AM -0600, Erick Erickson , wrote:
> OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s 
> too long.
>
> To Cassandra’s point: I fully sympathize for two reasons:
>
> 1> the more we all can use Gradle all the time, the faster it’ll get into its 
> final shape
>
> 2> the longer we have to add patches, the harder it’ll be to backport
>
> Therefore I’m going to push for back-porting Real Soon Now, next weekend if 
> possible. As soon as we have evidence that the Gradle build doesn’t break 
> Solr, i.e. Jenkins master builds using Ant don’t start breaking due to this, 
> I propose to back-port to 8x.
>
> Let the fun begin!
>
> Erick
>
> > On Nov 8, 2019, at 8:30 PM, Gus Heck  wrote:
> >
> > +1 to option 2
> >
> > On Thu, Nov 7, 2019 at 6:23 PM David Smiley  
> > wrote:
> >
> > Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve 
> > on one branch while it’s new.
> >
> > On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand  wrote:
> > I'd be fine with option 2 but I have a slight preference for option 3.
> > If we see the Gradle build as the future default build, then we need
> > to start using it and I wonder that having to use a different workflow
> > on branch_8x would be an incentive to keep using the Ant build
> > instead.
> >
> > On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett  
> > wrote:
> > >
> > > I’m fine with Option 2.
> > >
> > > Putting my project manager hat on, I’d really like to see a central list 
> > > or Jira issues of the things we want to make sure to do before we can 
> > > turn off Ant. The list/sub-tasks could be compiled after it’s merged to 
> > > master, but it would be nice if we could approach this in a coordinated 
> > > way so we’re all able to figure out quickly what remains - I think we’ll 
> > > have a higher chance of faster success that way. Hopefully also people 
> > > would sign up for the things that they will volunteer to drive to 
> > > completion instead of hanging back because they aren’t sure what needs to 
> > > be done.
> > >
> > > Dawid and I worked on the Ref Guide transition to Gradle in a separate 
> > > branch and it’s either finished or very close to it IMO. It includes the 
> > > PR I put up last night to remove the PDF build tasks. I just need to 
> > > merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I 
> > > will try to do by tomorrow.
> > >
> > > Cassandra
> > > On Nov 6, 2019, 3:07 PM -0600, David Smiley , 
> > > wrote:
> > >
> > > Option 2.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson  
> > > wrote:
> > > >
> > > > All:
> > > >
> > > > re: SOLR-13452. I’m now coming down on both sides of the issue. My 
> > > > motive here is if this was pushed, even in its current incomplete 
> > > > state, people would have an easier time contributing to the effort. Of 
> > > > course this means I would be asking people to use the gradle build at 
> > > > least on master if at all possible.
> > > >
> > > > There are several assumptions I’m making here:
> > > >
> > > > - we can keep running the Ant build as long as necessary. Ant would be 
> > > > our primary build process. The purpose of pushing the current Gradle 
> > > > effort is to make it easier for others to contribute and “just try it”.
> > > >
> > > > - There are no conflicts between the Gradle and Ant builds, so we can 
> > > > continue to use Ant as necessary until we make the switch.
> > > >
> > > > - people will commit up front to putting some effort into this. I flat 
> > > > guarantee I won’t carry the load alone. If nobody else steps up, I’ll 
> > > > table it. I will volunteer to push fixes from non-committers.
> > > > — Yes, people can do this already with the gradle_8 branch, it’d 

Re: Gradle build

[Cassandra Targett]

I’m fine with Option 2.

Putting my project manager hat on, I’d really like to see a central list or 
Jira issues of the things we want to make sure to do before we can turn off 
Ant. The list/sub-tasks could be compiled after it’s merged to master, but it 
would be nice if we could approach this in a coordinated way so we’re all able 
to figure out quickly what remains - I think we’ll have a higher chance of 
faster success that way. Hopefully also people would sign up for the things 
that they will volunteer to drive to completion instead of hanging back because 
they aren’t sure what needs to be done.

Dawid and I worked on the Ref Guide transition to Gradle in a separate branch 
and it’s either finished or very close to it IMO. It includes the PR I put up 
last night to remove the PDF build tasks. I just need to merge it into the main 
Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow.

Cassandra
On Nov 6, 2019, 3:07 PM -0600, David Smiley , wrote:
> Option 2.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson  
> > wrote:
> > > All:
> > >
> > > re: SOLR-13452. I’m now coming down on both sides of the issue. My motive 
> > > here is if this was pushed, even in its current incomplete state, people 
> > > would have an easier time contributing to the effort. Of course this 
> > > means I would be asking people to use the gradle build at least on master 
> > > if at all possible.
> > >
> > > There are several assumptions I’m making here:
> > >
> > > - we can keep running the Ant build as long as necessary. Ant would be 
> > > our primary build process. The purpose of pushing the current Gradle 
> > > effort is to make it easier for others to contribute and “just try it”.
> > >
> > > - There are no conflicts between the Gradle and Ant builds, so we can 
> > > continue to use Ant as necessary until we make the switch.
> > >
> > > - people will commit up front to putting some effort into this. I flat 
> > > guarantee I won’t carry the load alone. If nobody else steps up, I’ll 
> > > table it. I will volunteer to push fixes from non-committers.
> > > — Yes, people can do this already with the gradle_8 branch, it’d just be 
> > > easier if it was already in the pull.
> > >
> > > - moving to Gradle as our primary workflow won’t happen until we work out 
> > > some of the kinks, things like.
> > > — running on Jenkins.
> > > — Getting the equivalent of “ant server dist” to run.
> > > — Getting the ref guide built.
> > > — I’m sure other things will crop up.
> > >
> > >
> > > So there are several options, please let me know which one you prefer:
> > >
> > > 1. do nothing. People can check out the gradle_8 build and work on it. 
> > > There has been some of this so far, many thanks.
> > >
> > > 2. merge it into master only. TBD is when we take Ant out of master.
> > >
> > > 3. merge into both master and 8x. Assuming we can continue to use both, 
> > > I’m not sure what advantage there is to merging into 8x. This seems like 
> > > something that should come along with a major version release.
> > >
> > > 4. wait until it’s feature-complete. Based on the evidence so far, this 
> > > may be a long time coming.
> > >
> > > Also, the timing is fungible. I don’t see a downside as long as we can 
> > > continue to build with Ant. I certainly _do_ see a downside if we have to 
> > > do everything Ant does immediately after pushing to whatever branches.
> > >
> > > Erick
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >

Re: ReleaseWizard tool

[Cassandra Targett]

That explains it - I suspected it didn’t have anything to do with the Ref 
Guide, but wanted to be sure.

Very nice, thanks for working on it!

Cassandra
On Nov 6, 2019, 2:48 PM -0600, Jan Høydahl , wrote:
> It has nothing to do with the RefGuide :)
> It will generate a "release TODO" document in adoc format for this specific 
> release, which details all the phases, all the steps in each phase, and all 
> the exact cmdline commands, with correct paths and version numbers, to run 
> for each step.
> You don't really need it, because the interactive CLI menus in the tool keeps 
> you up to date on what steps remain and what to do, but it is nice for a full 
> overview of the process for preparation or whatever.
> The guide will be different if you are doing a major, minor or bugfix 
> release, as there are different steps needed for each.
> Then we generate a HTML page with embedded CSS from the adoc, see 
> https://www.dropbox.com/s/ug9yckvbwqwetvs/Lucene%3ASolr%20Release%208.3.0.html?dl=0
>  for an example HTML, and 
> https://www.dropbox.com/s/wulog2ipweth4mp/lucene_solr_release_8.3.0.adoc?dl=0 
> for the corresponding adoc. Try it :)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 6. nov. 2019 kl. 21:32 skrev Cassandra Targett :
> >
> > I was far too swamped back in July to be able to take a look at this new 
> > tool, but I’ve had a few minutes now and while I’ve never done a release, 
> > it really looks very helpful.
> >
> > Jan, I note in your initial description in this thread and in LUCENE-8852 
> > you mention the release wizard tool allows you to "generate a full Asciidoc 
> > guide for the release” - what is it generating? I’m not a python expert, 
> > but I did notice it requires & uses the asciidoctor gem. That’s not how we 
> > make the Ref Guide so it must be for another purpose, but I’m not able to 
> > fully figure it out.
> >
> > Sorry for the late thread resurrection, as I said I only now have a bit of 
> > time to catch up here.
> >
> > Thanks,
> > Cassandra
> > On Jul 5, 2019, 3:11 PM -0500, Jan Høydahl , wrote:
> > > Go for it. For me it was a very interesting experience, and I will likely 
> > > do it again at some point!
> > >
> > > Jan Høydahl
> > >
> > > 5. jul. 2019 kl. 21:00 skrev David Smiley :
> > >
> > > > Nice Jan!  Maybe I'll be an RM one day, now that there's a nice tool to 
> > > > help :-)
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley
> > > >
> > > >
> > > > > On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl  
> > > > > wrote:
> > > > > > I wrote an article at LinkedIN pulse about the release process and 
> > > > > > the tool:
> > > > > > https://www.linkedin.com/pulse/releasing-lucene-just-61-steps-jan-høydahl/
> > > > > >
> > > > > > --
> > > > > > Jan Høydahl, search solution architect
> > > > > > Cominvent AS - www.cominvent.com
> > > > > >
> > > > > > > 11. jun. 2019 kl. 10:46 skrev Jan Høydahl :
> > > > > > >
> > > > > > > I have now pushed the ReleaseWizard tool in 
> > > > > > > https://issues.apache.org/jira/browse/LUCENE-8852
> > > > > > > Appreciate all kind of feedback!
> > > > > > >
> > > > > > > --
> > > > > > > Jan Høydahl, search solution architect
> > > > > > > Cominvent AS - www.cominvent.com
> > > > > > >
> > > > > > > > 1. jun. 2019 kl. 20:26 skrev Jan Høydahl 
> > > > > > > > :
> > > > > > > >
> > > > > > > > As I said, I’ll start a thread about this, please reply to that 
> > > > > > > > instead of continuing discussion in this thread which is about 
> > > > > > > > releaseWizard :)
> > > > > > > >
> > > > > > > > Jan Høydahl
> > > > > > > >
> > > > > > > > 1. jun. 2019 kl. 15:53 skrev Michael Sokolov 
> > > > > > > > :
> > > > > > > >
> > > > > > > > > I'm not sure what the proper way to use fix version is. 
> > > > > > > > > Suppose you back port a fix to mu

Re: ReleaseWizard tool

[Cassandra Targett]

I was far too swamped back in July to be able to take a look at this new tool, 
but I’ve had a few minutes now and while I’ve never done a release, it really 
looks very helpful.

Jan, I note in your initial description in this thread and in LUCENE-8852 you 
mention the release wizard tool allows you to "generate a full Asciidoc guide 
for the release” - what is it generating? I’m not a python expert, but I did 
notice it requires & uses the asciidoctor gem. That’s not how we make the Ref 
Guide so it must be for another purpose, but I’m not able to fully figure it 
out.

Sorry for the late thread resurrection, as I said I only now have a bit of time 
to catch up here.

Thanks,
Cassandra
On Jul 5, 2019, 3:11 PM -0500, Jan Høydahl , wrote:
> Go for it. For me it was a very interesting experience, and I will likely do 
> it again at some point!
>
> Jan Høydahl
>
> 5. jul. 2019 kl. 21:00 skrev David Smiley :
>
> > Nice Jan!  Maybe I'll be an RM one day, now that there's a nice tool to 
> > help :-)
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > > On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl  wrote:
> > > > I wrote an article at LinkedIN pulse about the release process and the 
> > > > tool:
> > > > https://www.linkedin.com/pulse/releasing-lucene-just-61-steps-jan-høydahl/
> > > >
> > > > --
> > > > Jan Høydahl, search solution architect
> > > > Cominvent AS - www.cominvent.com
> > > >
> > > > > 11. jun. 2019 kl. 10:46 skrev Jan Høydahl :
> > > > >
> > > > > I have now pushed the ReleaseWizard tool in 
> > > > > https://issues.apache.org/jira/browse/LUCENE-8852
> > > > > Appreciate all kind of feedback!
> > > > >
> > > > > --
> > > > > Jan Høydahl, search solution architect
> > > > > Cominvent AS - www.cominvent.com
> > > > >
> > > > > > 1. jun. 2019 kl. 20:26 skrev Jan Høydahl :
> > > > > >
> > > > > > As I said, I’ll start a thread about this, please reply to that 
> > > > > > instead of continuing discussion in this thread which is about 
> > > > > > releaseWizard :)
> > > > > >
> > > > > > Jan Høydahl
> > > > > >
> > > > > > 1. jun. 2019 kl. 15:53 skrev Michael Sokolov :
> > > > > >
> > > > > > > I'm not sure what the proper way to use fix version is. Suppose 
> > > > > > > you back port a fix to multiple branches? Should fixVersion list 
> > > > > > > all of them? Just pick one?
> > > > > > >
> > > > > > > > On Wed, May 29, 2019, 6:00 PM Jan Høydahl 
> > > > > > > >  wrote:
> > > > > > > > > My releaseWizard tool is getting more complete as the 7.7.2 
> > > > > > > > > release progresses. Will share the code just after I complete 
> > > > > > > > > all steps.
> > > > > > > > >
> > > > > > > > > I tested relasedocmaker and it digs up all the JIRA issues 
> > > > > > > > > marked as RESOLVED for the version and creates two files.
> > > > > > > > > CHANGELOG.md simply lists all issues under headings 
> > > > > > > > > IMPROVEMENTS, BUG FIXES etc
> > > > > > > > > One problem I found with how the CHANGELOG works is that it 
> > > > > > > > > adds all issues having the version in fixVersion, even if the 
> > > > > > > > > feature
> > > > > > > > > was already released in an earlier version. That is because 
> > > > > > > > > of the way we use JIRA fixVersion, adding both e.g. "master 
> > > > > > > > > (9.0)" and "8.2"
> > > > > > > > > at the same time, even if we know that 8.2 is the version the 
> > > > > > > > > feature will be released. If we stop always adding "master" 
> > > > > > > > > to fixVersion
> > > > > > > > > but strive to keep it a list of version the feature/bugfix is 
> > > > > > > > > FIRST introduced, then this tool will do the correct job.
> > > > > > > > >
> > > > > > > > > RELEASENOTES.md lists "...new developer and user-facing 
> > > > > > > > > incompatibilities, important issues, features, and major 
> > > > > > > > > improvements.".
> > > > > > > > > And if we enable the JIRA field "Release Notes" (we don't 
> > > > > > > > > have it now), the content of that field will be used in the 
> > > > > > > > > release notes instead of the JIRA description.
> > > > > > > > > You can select any issue to surface in RELEASENOTES by adding 
> > > > > > > > > a certain label, by default "backward-incompatible".
> > > > > > > > >
> > > > > > > > > I think it could be a welcome addition to our flow. We cant' 
> > > > > > > > > expect the output from the tool to be used as-is, sometimes a 
> > > > > > > > > major feature spans multiple
> > > > > > > > > JIRAs etc, but it could be a good starting point, and would 
> > > > > > > > > shift the burden of documenting important and breaking 
> > > > > > > > > changes from release-time to commit-time,
> > > > > > > > > if we as committers manage to adjust our routines. We could 
> > > > > > > > > even have a weekly job that runs the releasedocmaker and 
> > > > > > > > > sends the output to dev@ list for active branches, to keep 
> > > > > > > > > focus.
> > > > > > > > >
> > > > > > > 

Re: [ANNOUNCE] Apache Solr 8.3.0 released

[Cassandra Targett]

We’re still working out the changes to the publication process, and got a 
couple wires crossed that prevented the Ref Guide from being published at the 
same time for this release.

I’ve published the final version now: http://lucene.apache.org/solr/guide/8_3/.

Apologies for the confusion, by the next release we expect to have all this 
worked out.
On Nov 4, 2019, 2:30 AM -0600, Paras Lehana , wrote:
> Hey Ishan,
>
> Somedays back it was announced that the foundation will majorly focus on
> HTML guides now and thus, 8.2 guide was released (which was said to be
> shorter than 8.0). C*an we expect Ref Guide 8.3 in coming days* or maybe is
> it not required? Asking because we are planning to upgrade to latest stable
> Solr versions and to keep us updated all times, we will be referring the
> latest guides and incorporated changes in each release.
>
> On Sun, 3 Nov 2019 at 04:34, Ishan Chattopadhyaya 
> wrote:
>
> > ## 2 November 2019, Apache Solr™ 8.3.0 available
> >
> > The Lucene PMC is pleased to announce the release of Apache Solr 8.3.0.
> >
> > Solr is the popular, blazing fast, open source NoSQL search platform
> > from the Apache Lucene project. Its major features include powerful
> > full-text search, hit highlighting, faceted search, dynamic
> > clustering, database integration, rich document handling, and
> > geospatial search. Solr is highly scalable, providing fault tolerant
> > distributed search and indexing, and powers the search and navigation
> > features of many of the world's largest internet sites.
> >
> > Solr 8.3.0 is available for immediate download at:
> >
> > 
> >
> > ### Solr 8.3.0 Release Highlights:
> >
> > *Two dimensional routed aliases are now available for organizing
> > collections based on the data values of two fields
> > *SPLITSHARD implements a new splitByPrefix option that takes into
> > account the actual document distribution when using compositeIds
> > *QueryElevationComponent can have query rules configured with
> > match="subset" wherein the words need only match a subset of the
> > query's words and in any order
> > *Command line option to export documents to a file
> > *Support deterministic replica routing preferences for better cache usage
> > *Ability to query aliases in Solr Admin UI
> > *JWTAuthPlugin supports multiple JWKS endpoints and multiple IdP issuers
> > *JSON faceting now supports arbitrary ranges for range facets
> > *Support integral plots, cosine distance and string truncation with
> > math expressions (Joel Bernstein)
> > *New cat() stream source to create tuples from lines in local files
> > *Add upper, lower, trim and split Stream Evaluators
> > *Add CsvStream, TsvStream Streaming Expressions and supporting
> > Stream Evaluators
> > *Add CaffeineCache, an efficient implementation of SolrCache
> > *Live SPLITSHARD can lose updates due to cluster state change
> > between checking if the current shard is active and later checking if
> > there are any sub-shard leaders to forward the update to
> > *Fix for SPLITSHARD (async) with failures in underlying
> > sub-operations can result in data loss
> > *Allow dynamic resizing of SolrCache-s
> > *Allow optional redaction of data saved by 'bin/solr autoscaling -save'
> > *Optimized large managed schema modifications (internal O(n^2) problem)
> > *Max idle time support for SolrCache implementations
> > *Add Prometheus Exporter GC and Heap options
> > *SSL: Adding Enabling/Disabling client's hostname verification config
> > *Introducing SolrClient.ping(collection) in SolrJ
> > *Fix for CDCR bootstrap not replicating index to the replicas of
> > target cluster
> > *Fixed a race condition when initializing metrics for new security
> > plugins on security.json change
> > *Fixed JWTAuthPlugin to update metrics prior to continuing w/other
> > filters or returning error
> > *Fixed distributed grouping when multiple 'fl' params are specified
> > *JMX MBeans are not exposed because of race condition between
> > creating platform mbean server and registering mbeans
> > *Fix for class-cast issues during atomic-update 'removeregex' operations
> > *Fix for multi-node race condition to create/remove nodeLost markers
> > *Fix for too many cascading calls to remote servers, which can bring
> > down nodes
> > *Fix for MOVEREPLICA ignoring replica type and always adding 'nrt'
> > replicas
> > *Fix: DistributedZkUpdateProcessor should propagate URP.finish()
> > lifecycle (regression since 8.1)
> >
> >
> > Please read CHANGES.txt for a full list of new features and changes:
> >
> > 
> >
> > Solr 8.3.0 also includes features, optimizations and bugfixes in the
> > corresponding Apache Lucene release:
> >
> > 
> >
> >
> > Note: The Apache Software Foundation uses an extensive mirroring network
> > for
> > distributing releases. It is possible that the mirror you 

Re: Rethinking how we publish the Solr Ref Guide

[Cassandra Targett]

Yes, it does need to be updated. I was waiting to do that until I informed the 
user list about the change to not publish a PDF any longer which I’m ready to 
send now, so I’ll also fix the redirect link.

Cassandra
On Oct 28, 2019, 12:23 PM -0500, Gus Heck , wrote:
> Ah yes I assumed that the original link had come from a good source... OTOH 
> https://lucene.apache.org/solr/guide/field-types-included-with-solr.html 
> still needs to be updated to point to 8_2 I think.
>
> > On Mon, Oct 28, 2019 at 1:01 PM Chris Hostetter  
> > wrote:
> > >
> > > : The redirection is wrong, if you remove "latest" from the urls with 8_1 
> > > in
> > >
> > > The "redirection" rules appear to be working as designed -- but AFAIK they
> > > were never designed with any idea of having a "latest/" path.
> > >
> > > the Latest URL has no is just the page name w/o a version number, not the
> > > page name prefixed with "latest/".
> > >
> > > Specifically this is suppose to be the "latest" URL for the page in
> > > question...
> > >
> > > https://lucene.apache.org/solr/guide/field-types-included-with-solr.html
> > >
> > > : > I was trying to access
> > > : > 
> > > https://lucene.apache.org/solr/guide/latest/field-types-included-with-solr.html
> > >
> > > ...where did you find that link?
> > >
> > > I'm pretty sure the place that linked to that URL is the place that has a
> > > mistake.
> > >
> > >
> > >
> > > -Hoss
> > > http://www.lucidworks.com/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

Re: Rethinking how we publish the Solr Ref Guide

[Cassandra Targett]

FYI, bumping this - I’m about to send a mail to the user list explaining why 
we’ve stopped releasing the PDF.

I think I said originally we’d publish the 8.2 PDF, but I’ve changed my mind on 
that and edited the Ref Guide landing page to include 8.2 and indicate it is 
HTML only starting with 8.2.

If there is an outcry in the community about the change, we can discuss other 
options depending on the feedback.

Cassandra
On Sep 23, 2019, 9:54 AM -0500, Jason Gerlowski , wrote:
> +1. That all sounds good to me. Excited to see some streamlining here.
>
> On Fri, Sep 20, 2019 at 3:46 PM Cassandra Targett  
> wrote:
> >
> > Thanks everyone, by the way, for the encouragement and feedback here.
> >
> > For next steps, how do folks feel about making the change to stop voting on 
> > the PDF *now*? Or, I guess, retroactively for 8.2 since that’s not out yet. 
> > I could push the HTML and make a PDF but announce to the list that from 8.2 
> > forward we consider the HTML the main Ref Guide and the PDF is “for 
> > convenience” (and explain the thinking behind it).
> >
> > If we want a VOTE on this policy change, I can do that - I feel like we 
> > have consensus without it, but we could be more formal about it if folks 
> > prefer.
> >
> > For 8.3 we'll see what we can get automated there, but if it’s not ready 
> > I’ll just do it manually once the RC is out.
> >
> > I’ll file a Jira for some of the changes I’ll make to the docs for the 
> > process, etc., and another one for automation ideas.
> >
> > Cassandra
> > On Sep 19, 2019, 2:53 PM -0500, Noble Paul , wrote:
> >
> > First of all a big thanks to Cassandra to help coordinate and build
> > our ref guide to make it professional. It really used to be pathetic
> > before you took over
> >
> > . Yes we need to avoid "creating work" . There should be no need for a
> > ref guide release.
> >
> > +1 for your plan
> >
> > On Thu, Sep 19, 2019 at 11:57 PM Cassandra Targett
> >  wrote:
> >
> >
> > The pages do already have a “Site last generated” date on them at the 
> > bottom. It’s specifically worded that way for a reason.
> >
> > We actually wanted the date the .adoc file was last updated to be in the 
> > footer too, but the problem has always been that a static site generator 
> > always regenerates all pages every time - so every single page, edited or 
> > not, always has the same exact date on it.
> >
> > And, our build works by copying everything under `solr/solr-ref-guide/src` 
> > to `solr/build`, so every file really has a create date and last updated 
> > date that are always the date you do the build. Basically, the files you 
> > see and work with are not actually the same files that get built - we build 
> > from copies that are made at build-time.
> >
> > (That’s all why it says “Site last generated” instead of “Last updated”.)
> >
> > I’m not saying there’s no way to add a last updated date for the underlying 
> > file, it’s just not obvious how to do it so we skipped it.
> >
> > No problem, though, adding a link to Github - that’s actually kind of a 
> > different thing and I’m pretty sure we could do that right now.
> >
> > Cassandra
> > On Sep 19, 2019, 7:07 AM -0500, Anshum Gupta , 
> > wrote:
> >
> > I agree that we should be able to fix mistakes, my only suggestion was that 
> > those mistakes not be non-trivial. But the more I think about it, the more 
> > I feel convinced about just publishing the updates - however, having a time 
> > stamp on when the guide was last updated would be nice to have. Anything 
> > else would require much more effort and I'm not sure it's worth it.
> >
> > On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter  
> > wrote:
> >
> >
> >
> > : > However Anshum does make a good point that users wouldn't know when
> > : the pages have changed. I think it would be great to have a link on each
> > : ref-guide page that shows the last modified date and links to the
> > : history of that page in github
> >
> > : Perhaps we could instead provide a single HTML page or HTML table as
> > : part of or alongside each guide, showing all commits touching the guide
> > : on that branch after the release. Could probably be baked in as part of
> > : the release script. Using the release date or git hash for the release,
> >
> > Yeah, there are a lot of options we could pursue for generating a
> > "changes" list as part of an automated build process -- but i would
> > consider this idea a "nice to

Re: [VOTE] Release Lucene/Solr 8.3.0 RC1

[Cassandra Targett]

Since we’re only sort of half-way through revamping the Solr Ref Guide release 
process, I’ve manually pushed up the 8.3 Ref Guide with a DRAFT watermark if 
anyone would like to review it while looking at the packages: 
https://lucene.apache.org/solr/guide/8_3/.

Cassandra
On Oct 21, 2019, 2:17 PM -0500, Alexandre Rafalovitch , 
wrote:
> Super minor documentation note:
> In the HTML changes file, the parsing of - I guess - SOLR-12368 record
> makes the authors information become a separate point.
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.0-RC1-revd796eca84dbabe3ae9b3c27afc01ef3bee35acb1/solr/changes/Changes.html#v8.3.0.improvements
>
> Regards,
> Alex.
>
> On Mon, 21 Oct 2019 at 13:51, Ishan Chattopadhyaya
>  wrote:
> >
> > Please vote for release candidate 1 for Lucene/Solr 8.3.0
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.0-RC1-revd796eca84dbabe3ae9b3c27afc01ef3bee35acb1
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.0-RC1-revd796eca84dbabe3ae9b3c27afc01ef3bee35acb1
> >
> > The vote will be open for at least 3 working days, i.e. until
> > 2019-10-24 18:00 UTC.
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Here is my +1
> >
> > -
> > 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: 8.3 release

[Cassandra Targett]

On Oct 19, 2019, 1:32 PM -0500, Ishan Chattopadhyaya 
, wrote:
> Thanks a lot Andrzej and Shalin.
> I'll try to build the RC on Monday. FYI, upon Jan's advice, I'll be using his 
> release wizard tool. Also, I'll need to dig into the simultaneous refguide 
> release situation. So, i might need help with both along the way.

The new Ref Guide how-to-publish docs aren’t ready yet - I have them in a local 
branch - and we have done no work yet on any Jenkins builds to publish things, 
so for 8.3 why don’t I follow the process manually for you for this release:

• When you get the RC up, I’ll put the 8.3 docs uploaded to the site with the 
DRAFT watermark (I see the VOTE thread, so I’ll do that now, and reply to the 
thread with the URL).
• When you publish the artifacts, I’ll replace the DRAFT watermark with the 
final version.
• You will be able to include a link to the HTML docs in your Solr release 
announcement.

Between now and then, I also need to send a note to the user list informing 
users of the no-more-PDF change (I have a draft of this ready to go also).

Sound reasonable?

Cassandra

Re: The Lucene Solr Gradle Build Game plan

[Cassandra Targett]

On Oct 17, 2019, 11:03 AM -0500, Dawid Weiss , wrote:
> > I’m not sure the next steps here - we could merge the changed files into 
> > the main Gradle branch?
>
> I'm kind of waiting for Mark to coordinate this, actually. I've
> modified some test code on the gradle branch but Mark has been talking
> about changes he's made locally so I don't know if it makes sense to
> put more work into something that may be thrown away. A patch on the
> existing refguide branch is fine I think since it can always be
> reapplied.

OK, that makes sense.

>
> > My next project is going to be ripping out the PDF builds from the Ref 
> > Guide build process, so that will also eventually require more changes here.
>
> What do you mean by this? Isn't buildPdf doing that already?
>
We decided recently to no longer publish the PDF and focus on the HTML version: 
https://issues.apache.org/jira/browse/SOLR-13782. We might have skipped that in 
the Gradle build, but I knew I wasn’t going to have time then to figure out 
what we didn’t need. Some things have changed, though, and I will have time in 
the next few weeks to work on it. We also haven’t told the general user 
community about this yet, and I think there’s a chance they will want us to 
still produce a PDF in some form so we may end up keeping it.

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

Re: The Lucene Solr Gradle Build Game plan

[Cassandra Targett]

I’ve just pushed some changes to the "jira/SOLR-13452_gradle_7_refguide” branch 
- two cherry-picks from my recent changes for SOLR-12786 updating the docs for 
later Asciidoc versions, a couple outlier fixes I made in other commits to 
master I didn’t want to cherry-pick, and finally my edits to build.gradle 
building on the great work Dawid did for this. All the targets work now - we 
can call this done!

Thank you so much Dawid for your help with this, I never would have been able 
to do this on my own.

I’m not sure the next steps here - we could merge the changed files into the 
main Gradle branch? Not sure when that was last rebased with master, but a 
bunch of various changes might be needed. We could hold this in this branch 
until the next rebase?

My next project is going to be ripping out the PDF builds from the Ref Guide 
build process, so that will also eventually require more changes here.

Cassandra
On Oct 13, 2019, 8:58 AM -0500, Erick Erickson , wrote:
> Agree entirely with Dawid.
>
> > On Oct 11, 2019, at 5:54 PM, Dawid Weiss  wrote:
> >
> > That's entirely up to you, Cassandra. I tried to use Rouge but
> > couldn't get it to work. Please feel free to upgrade to newer versions
> > of those tools -- if it works we should be using newer, supported
> > version lines I think.
> >
> > Dawid
> >
> > On Fri, Oct 11, 2019 at 10:20 PM Cassandra Targett
> >  wrote:
> > >
> > > I had a number of problems getting either Jekyll build to run at all - it 
> > > kept getting stuck in various places.
> > >
> > > I eventually traced the problem to the pygments.rb plugin - I have 
> > > python, so it didn’t complain about it missing, just kept throwing errors 
> > > about missing header in a file. But when I took it out everything started 
> > > working.
> > >
> > > So I swapped it out for Rouge which is Ruby-based and comes with Jekyll. 
> > > However, it wasn't really well supported until Asciidoctor 2.x, so we 
> > > either lose syntax highlighting entirely or upgrade Asciidoctor & 
> > > jekyll-asciidoc version to get the better support.
> > >
> > > If we go with the older version of Asciidoctor we also have to downgrade 
> > > Slim to 3.0.1 since I found a bug a year ago using the 4.0.1 version of 
> > > Slim with Jekyll-asciidoc, which has since been fixed in the later 
> > > versions.
> > >
> > > The whole reason we hadn’t upgraded Asciidoctor was because people needed 
> > > to install it locally to get our old build to run, and I wasn’t sure how 
> > > to force folks to update their local version. However, with Gradle we can 
> > > force the version we want because the build is handling the dependencies.
> > >
> > > So, the choice is - downgrade the Asciidoctor version and lose syntax 
> > > highlighting, or I could upgrade Asciidoctor for the project now (in the 
> > > Ant build & Jenkins jobs) and fix the pages that will fail the validation 
> > > check. As soon as those pages are fixed, the Gradle build will work fine.
> > >
> > > Cassandra
> > > On Oct 11, 2019, 1:28 PM -0500, Dawid Weiss , 
> > > wrote:
> > >
> > >
> > > Sure. Try and see if you can make it work. It is just about the only 
> > > thing that still needs to be done, the rest works like a charm.
> > >
> > > On Fri, Oct 11, 2019, 20:20 Cassandra Targett  
> > > wrote:
> > > >
> > > > Sorry for the delay getting back to you Dawid. That problem is actually 
> > > > because of the Asciidoctor version. The jekyll-asciidoc plugin will 
> > > > install Asciidoctor if it is not already installed, and it installs a 
> > > > version where the way the links are constructed is different and breaks 
> > > > our validation.
> > > >
> > > > More details about why this happens (if you’re curious) is in 
> > > > https://issues.apache.org/jira/browse/SOLR-12786?focusedCommentId=16622115=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16622115
> > > >
> > > > Both the Jenkins script used for Jenkins Ref Guide jobs 
> > > > (./dev-tools/scripts/jenkins.build.ref.guide.sh) and the Ref Guide 
> > > > README (./solr/solr-ref-guide/README.adoc) show examples of how to make 
> > > > sure the right Asciidoctor version is installed - the easiest is to 
> > > > install the Asciidoctor gem version we want first. Let me see if I can 
> > > > insert a line to install before the jekyll-asciidoc gem and see if that 
>

Re: 8.3 release

[Cassandra Targett]

Done, Ishan, thanks!

Cassandra
On Oct 16, 2019, 2:37 PM -0500, Ishan Chattopadhyaya 
, wrote:
> +1, Cassandra! Thanks.
>
> > On Wed, 16 Oct, 2019, 11:41 PM Cassandra Targett,  
> > wrote:
> > > Sorry, I meant branch_8_3.
> > >
> > > Cassandra
> > > On Oct 16, 2019, 12:59 PM -0500, Cassandra Targett 
> > > , wrote:
> > > > I just committed to master and branch_8x 
> > > > https://issues.apache.org/jira/browse/SOLR-12786 to update the versions 
> > > > of tools we use for building the Ref Guide. I’d like to commit that 
> > > > into branch_8_x if you don’t mind, Ishan? It’s not urgent, though.
> > > >
> > > > Cassandra
> > > > On Oct 16, 2019, 11:36 AM -0500, Alan Woodward , 
> > > > wrote:
> > > > > LUCENE-9005 is committed.
> > > > >
> > > > > > On 16 Oct 2019, at 17:12, Jan Høydahl  wrote:
> > > > > >
> > > > > > SOLR-13835 is also almost there.
> > > > > >
> > > > > > Jan Høydahl
> > > > > >
> > > > > > > 16. okt. 2019 kl. 16:53 skrev Adrien Grand :
> > > > > > >
> > > > > > > Hi Ishan,
> > > > > > >
> > > > > > > LUCENE-8920 needs more work indeed, but it is not blocking this 
> > > > > > > release.
> > > > > > >
> > > > > > > On Wed, Oct 16, 2019 at 3:54 PM Ishan Chattopadhyaya
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > > Here are the issues that remain to be resolved for 8.3.
> > > > > > > >
> > > > > > > > LUCENE-8920: Committed, but not resolved. More work remains?
> > > > > > > > LUCENE-9005: Patch available, not committed.
> > > > > > > > SOLR-13677: Patch available, not committed. Need another day to
> > > > > > > > complete cleanup and tests.
> > > > > > > >
> > > > > > > > I'll wait until all of them are finished and then proceed to 
> > > > > > > > build the RC1.
> > > > > > > > Thanks and regards,
> > > > > > > > Ishan
> > > > > > > >
> > > > > > > > On Tue, Oct 15, 2019 at 2:58 PM Ishan Chattopadhyaya
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Sure, Noble, thanks! Next time, please use a single commit to 
> > > > > > > > > revert
> > > > > > > > > such features (you just used up 3 commits). branch_8_3's 
> > > > > > > > > history is
> > > > > > > > > now littered with SOLR-13821 commits and reverts that 
> > > > > > > > > shouldn't have
> > > > > > > > > been there :-)
> > > > > > > > >
> > > > > > > > > Thanks, Jan!
> > > > > > > > >
> > > > > > > > > On Tue, Oct 15, 2019 at 12:17 AM Noble Paul 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > > I'll revert the package store commits related to SOLR-13821 
> > > > > > > > > > in the 8.3
> > > > > > > > > > branch. It is supposed to be used by the (SOLR-13822) and 
> > > > > > > > > > it is not a
> > > > > > > > > > part of the 8.3 release.
> > > > > > > > > > --Noble
> > > > > > > > > >
> > > > > > > > > > On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Ishan,
> > > > > > > > > > >
> > > > > > > > > > > The release is no longer blocked on LUCENE-8920.
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya
> > > > > > > > > > >  wrote:
> > > > > > > > 

PLEASE READ if you build the Ref Guide HTML locally

[Cassandra Targett]

If you build the Ref Guide HTML files on your local machine, please note
the following changes to the build.

To build the Ref Guide HTML version locally, you must have several Ruby
gems installed as pre-requisites. I've just committed changes that require
newer versions of these gems.

You can update your existing gems with the "gem update" command:

gem update asciidoctor
gem update jekyll-asciidoc
gem update slim
gem update tilt

And a new dependency needs to be added:

gem install concurrent-ruby

* The version of Jekyll has not changed so that gem does not need to be
updated.

The versions we're now using are documented in the Ref Guide README:
https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/README.adoc

See also https://issues.apache.org/jira/browse/SOLR-12786 for details of
these changes.

As soon as we move to Gradle, you won't need any gems locally. The PDF
build downloads a .jar, so while it is also updated no local changes are
needed (and it's going away soon anyway).

Let me know if you have trouble with the new versions -
Cassandra

Re: [JENKINS] Solr-reference-guide-master - Build # 19516 - Failure

[Cassandra Targett]

I pushed a fix for this and it’s fine now.

Cassandra
On Oct 16, 2019, 12:05 PM -0500, Apache Jenkins Server 
, wrote:
> Build: https://builds.apache.org/job/Solr-reference-guide-master/19516/
>
> Log:
> Started by timer
> Running as SYSTEM
> [EnvInject] - Loading node environment variables.
> Building remotely on websites (git-websites svn-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> No credentials specified
> > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
> > git config remote.origin.url 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
> Cleaning workspace
> > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
> > git reset --hard # timeout=10
> > git clean -fdx # timeout=10
> Fetching upstream changes from 
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> > git --version # timeout=10
> > git fetch --tags --progress -- 
> > https://gitbox.apache.org/repos/asf/lucene-solr.git 
> > +refs/heads/*:refs/remotes/origin/*
> > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision f7711d712472528b567ab975d0ed677bbd30ac12 
> (refs/remotes/origin/master)
> > git config core.sparsecheckout # timeout=10
> > git checkout -f f7711d712472528b567ab975d0ed677bbd30ac12
> Commit message: "LUCENE-9005: BooleanQuery.visit() pulls subvisitors from a 
> top-level MUST visitor"
> > git rev-list --no-walk b881a09592d44aa114794c07d9f9cca41b2fcb1c # timeout=10
> No emails were triggered.
> [Solr-reference-guide-master] $ /bin/bash -xe 
> /tmp/jenkins15449213170578971340.sh
> + bash dev-tools/scripts/jenkins.build.ref.guide.sh
> + set -e
> + RVM_PATH=/home/jenkins/.rvm
> + RUBY_VERSION=ruby-2.5.1
> + GEMSET=solr-refguide-gemset
> + curl -sSL https://get.rvm.io
> + bash -s -- --ignore-dotfiles stable
> Turning on ignore dotfiles mode.
> Downloading https://github.com/rvm/rvm/archive/1.29.9.tar.gz
> Downloading 
> https://github.com/rvm/rvm/releases/download/1.29.9/1.29.9.tar.gz.asc
> gpg: Signature made Wed 10 Jul 2019 08:31:02 AM UTC
> gpg: using RSA key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
> gpg: Good signature from "Piotr Kuczynski " 
> [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
> GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.9.tgz'
> Upgrading the RVM installation in /home/jenkins/.rvm/
> Upgrade of RVM in /home/jenkins/.rvm/ is complete.
>
> Thanks for installing RVM 
> Please consider donating to our open collective to help us maintain RVM.
>
>  Donate: https://opencollective.com/rvm/donate
>
>
> + set +x
> Running 'source /home/jenkins/.rvm/scripts/rvm'
> Running 'rvm cleanup all'
> Cleaning up rvm archives
> Cleaning up rvm repos
> Cleaning up rvm src
> Cleaning up rvm log
> Cleaning up rvm tmp
> Cleaning up rvm gemsets
> Cleaning up rvm links
> Cleanup done.
> Running 'rvm autolibs disable'
> Running 'rvm install ruby-2.5.1'
> Already installed ruby-2.5.1.
> To reinstall use:
>
> rvm reinstall ruby-2.5.1
>
> Running 'rvm gemset create solr-refguide-gemset'
> ruby-2.5.1 - #gemset created 
> /home/jenkins/.rvm/gems/ruby-2.5.1@solr-refguide-gemset
> ruby-2.5.1 - #generating solr-refguide-gemset wrappers...
> Running 'rvm ruby-2.5.1@solr-refguide-gemset'
> Using /home/jenkins/.rvm/gems/ruby-2.5.1 with gemset solr-refguide-gemset
> Running 'gem install --force --version 3.5.0 jekyll'
> Successfully installed jekyll-3.5.0
> Parsing documentation for jekyll-3.5.0
> Done installing documentation for jekyll after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 3.0.0 jekyll-asciidoc'
> Successfully installed jekyll-asciidoc-3.0.0
> Parsing documentation for jekyll-asciidoc-3.0.0
> Installing ri documentation for jekyll-asciidoc-3.0.0
> Done installing documentation for jekyll-asciidoc after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 4.0.1 slim'
> Successfully installed slim-4.0.1
> Parsing documentation for slim-4.0.1
> Installing ri documentation for slim-4.0.1
> Done installing documentation for slim after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 2.0.10 tilt'
> Successfully installed tilt-2.0.10
> Parsing documentation for tilt-2.0.10
> Installing ri documentation for tilt-2.0.10
> Done installing documentation for tilt after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 1.1.5 concurrent-ruby'
> Successfully installed concurrent-ruby-1.1.5
> Parsing documentation for concurrent-ruby-1.1.5
> Installing ri documentation for concurrent-ruby-1.1.5
> Done installing documentation for concurrent-ruby after 4 seconds
> 1 gem installed
> + ant clean build-site build-pdf
> Buildfile: 
> 

Re: The Lucene Solr Gradle Build Game plan

[Cassandra Targett]

I had a number of problems getting either Jekyll build to run at all - it kept 
getting stuck in various places.

I eventually traced the problem to the pygments.rb plugin - I have python, so 
it didn’t complain about it missing, just kept throwing errors about missing 
header in a file. But when I took it out everything started working.

So I swapped it out for Rouge which is Ruby-based and comes with Jekyll. 
However, it wasn't really well supported until Asciidoctor 2.x, so we either 
lose syntax highlighting entirely or upgrade Asciidoctor & jekyll-asciidoc 
version to get the better support.

If we go with the older version of Asciidoctor we also have to downgrade Slim 
to 3.0.1 since I found a bug a year ago using the 4.0.1 version of Slim with 
Jekyll-asciidoc, which has since been fixed in the later versions.

The whole reason we hadn’t upgraded Asciidoctor was because people needed to 
install it locally to get our old build to run, and I wasn’t sure how to force 
folks to update their local version. However, with Gradle we can force the 
version we want because the build is handling the dependencies.

So, the choice is - downgrade the Asciidoctor version and lose syntax 
highlighting, or I could upgrade Asciidoctor for the project now (in the Ant 
build & Jenkins jobs) and fix the pages that will fail the validation check. As 
soon as those pages are fixed, the Gradle build will work fine.

Cassandra
On Oct 11, 2019, 1:28 PM -0500, Dawid Weiss , wrote:
>
> Sure. Try and see if you can make it work. It is just about the only thing 
> that still needs to be done, the rest works like a charm.
>
> > On Fri, Oct 11, 2019, 20:20 Cassandra Targett  wrote:
> > > Sorry for the delay getting back to you Dawid. That problem is actually 
> > > because of the Asciidoctor version. The jekyll-asciidoc plugin will 
> > > install Asciidoctor if it is not already installed, and it installs a 
> > > version where the way the links are constructed is different and breaks 
> > > our validation.
> > >
> > > More details about why this happens (if you’re curious) is in 
> > > https://issues.apache.org/jira/browse/SOLR-12786?focusedCommentId=16622115=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16622115
> > >
> > > Both the Jenkins script used for Jenkins Ref Guide jobs 
> > > (./dev-tools/scripts/jenkins.build.ref.guide.sh) and the Ref Guide README 
> > > (./solr/solr-ref-guide/README.adoc) show examples of how to make sure the 
> > > right Asciidoctor version is installed - the easiest is to install the 
> > > Asciidoctor gem version we want first. Let me see if I can insert a line 
> > > to install before the jekyll-asciidoc gem and see if that fixes it.
> > >
> > > Cassandra
> > > On Oct 10, 2019, 2:22 AM -0500, Dawid Weiss , 
> > > wrote:
> > > > Ping, ping. I wanted to finalize the build of solr ref guide since I
> > > > started it. Almost everything is working on the branch but I can't get
> > > > minor differences to work and I believe they're due to a different
> > > > jekyll version (than that mentioned in the docs).
> > > >
> > > > Specifically, the invalid links are because of asciidoc sections like
> > > > this (in the processed resource-and-plugin-loading.adoc):
> > > >
> > > > === solr_home/lib
> > > >
> > > > In bare bones html (pure asciidoctor) this gets emitted as:
> > > >
> > > > solr_home/lib
> > > >
> > > > but when compiled via jekyll this becomes:
> > > >
> > > > solr_home/lib
> > > >
> > > > which I can't really explain.
> > > >
> > > > Cassandra what's the exact version of jekyll that runs the compilation
> > > > that is working for you?
> > > >
> > > > D.
> > > >
> > > > On Fri, Oct 4, 2019 at 11:42 AM Dawid Weiss  
> > > > wrote:
> > > > >
> > > > > Seems like pygments is to blame for the python requirement... I didn't
> > > > > check but there seem to be ruby-only
> > > > > highlighters for jekyll as well:
> > > > >
> > > > > https://jekyll-windows.juthilo.com/3-syntax-highlighting/
> > > > >
> > > > > On Fri, Oct 4, 2019 at 11:39 AM Dawid Weiss  
> > > > > wrote:
> > > > > >
> > > > > > Hi Cassandra,
> > > > > >
> > > > > > Apologies this took so long -- I wasn't familiar with these
> > > > > > site-generation tools and the

Re: The Lucene Solr Gradle Build Game plan

[Cassandra Targett]

Sorry for the delay getting back to you Dawid. That problem is actually because 
of the Asciidoctor version. The jekyll-asciidoc plugin will install Asciidoctor 
if it is not already installed, and it installs a version where the way the 
links are constructed is different and breaks our validation.

More details about why this happens (if you’re curious) is in 
https://issues.apache.org/jira/browse/SOLR-12786?focusedCommentId=16622115=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16622115

Both the Jenkins script used for Jenkins Ref Guide jobs 
(./dev-tools/scripts/jenkins.build.ref.guide.sh) and the Ref Guide README 
(./solr/solr-ref-guide/README.adoc) show examples of how to make sure the right 
Asciidoctor version is installed - the easiest is to install the Asciidoctor 
gem version we want first. Let me see if I can insert a line to install before 
the jekyll-asciidoc gem and see if that fixes it.

Cassandra
On Oct 10, 2019, 2:22 AM -0500, Dawid Weiss , wrote:
> Ping, ping. I wanted to finalize the build of solr ref guide since I
> started it. Almost everything is working on the branch but I can't get
> minor differences to work and I believe they're due to a different
> jekyll version (than that mentioned in the docs).
>
> Specifically, the invalid links are because of asciidoc sections like
> this (in the processed resource-and-plugin-loading.adoc):
>
> === solr_home/lib
>
> In bare bones html (pure asciidoctor) this gets emitted as:
>
> solr_home/lib
>
> but when compiled via jekyll this becomes:
>
> solr_home/lib
>
> which I can't really explain.
>
> Cassandra what's the exact version of jekyll that runs the compilation
> that is working for you?
>
> D.
>
> On Fri, Oct 4, 2019 at 11:42 AM Dawid Weiss  wrote:
> >
> > Seems like pygments is to blame for the python requirement... I didn't
> > check but there seem to be ruby-only
> > highlighters for jekyll as well:
> >
> > https://jekyll-windows.juthilo.com/3-syntax-highlighting/
> >
> > On Fri, Oct 4, 2019 at 11:39 AM Dawid Weiss  wrote:
> > >
> > > Hi Cassandra,
> > >
> > > Apologies this took so long -- I wasn't familiar with these
> > > site-generation tools and the whole ecosystem is rather... fragile :)
> > > After a few attempts at using gradle plugins I eventually leaned
> > > towards using asciidoctor and jekyll explicitly (so that we know which
> > > versions are being used and don't have to rely on dependencies).
> > >
> > > I got bare bone html checking working, PDF generation working and site
> > > generation working although the final link check currently fail for me
> > > with a bunch of errors. This works for me on Windows... on Linux I get
> > > site-generation generate a strange error from within jekyll:
> > >
> > > Conversion error: Jekyll::AsciiDoc::Converter encountered an error
> > > while converting 'about-filters.adoc':
> > > Bad file descriptor - /usr/bin/python2
> > >
> > > I could install python but I don't see why it'd need it. Perhaps there
> > > is something in the docs that would avoid using python altogether but
> > > I haven't had the time to look into it.
> > >
> > > Please feel free to check out the jira/SOLR-13452_gradle_7_refguide
> > > branch and try to run:
> > >
> > > ./gradlew -p solr/solr-ref-guide buildPdf buildSite
> > >
> > > There is a lot of room for improvement -- from property substitution,
> > > through how the "tools" are handled at the moment to task naming but I
> > > left this for the future. The initial step would be probably to get
> > > the site generation running on Linux/ Macs but I'd gladly hand it over
> > > back to you -- I can help with Gradle but a the rest of those tools
> > > are a mistery to me.
> > >
> > > Dawid
> > >
> > > On Fri, Sep 27, 2019 at 7:53 PM Dawid Weiss  wrote:
> > > >
> > > >
> > > > No problem. I will get it to work entirely, but not before next week - 
> > > > I am away for the weekend.
> > > >
> > > > Dawid
> > > >
> > > > On Fri, Sep 27, 2019, 16:17 Cassandra Targett  
> > > > wrote:
> > > > >
> > > > > Thanks Dawid for working on this! I’ve been a bit swamped the last 
> > > > > couple of days but will take a look today at what you’ve been able to 
> > > > > do so far and see where we might need to go from here.
> > > > >
> > > > > Cassandra
> > > > > On Sep 26,

Re: The Lucene Solr Gradle Build Game plan

[Cassandra Targett]

Thanks Dawid for working on this! I’ve been a bit swamped the last couple of 
days but will take a look today at what you’ve been able to do so far and see 
where we might need to go from here.

Cassandra
On Sep 26, 2019, 7:25 AM -0500, Dawid Weiss , wrote:
> I agree. Although I also understand the concern of trying to merge the
> changes while we're in the transition period... it'd be hell. I'd say
> move as much stuff as possible with the current folder structure (and
> ignore what cannot be ported easily) then switch as soon as possible
> to gradle and hack the old cruft with a chainsaw...
>
> D.
>
> On Thu, Sep 26, 2019 at 2:13 PM Erick Erickson  
> wrote:
> >
> > Of course I’ll completely defer to Dawid and Mark (well and anybody else 
> > actually, you know, doing _work_), but just can’t resist chiming in ;).
> >
> > My vote would be to “do it the Gradle way”. Yes, it’s a PITA to learn new 
> > stuff and I won’t like it. Tough. I see no reason to carry a bunch of cruft 
> > around because “that the way we always did it”.
> >
> > If we lose functionality, that’s a different discussion, starting with “do 
> > we need that functionality". But jumping through hoops and having to 
> > maintain that awkwardness forever going forward just because we forced the 
> > Ant structure on Gradle strikes me as a poor trade off.
> >
> > That said, I’m not doing the work so I really have no vote. But don’t 
> > strain to do it the old way on my account ;)
> >
> > Erick
> >
> > P.S. Thanks Dawid for jumping in!
> >
> > > On Sep 26, 2019, at 3:57 AM, Dawid Weiss  wrote:
> > >
> > > I pushed it in to Lucene repo (it's on Cassandra's refguide branch
> > > anyway, so shouldn't interfere with anything else); seems like it's in
> > > better shape than previous code anyway (those questions I asked about
> > > the nature of the gradle port still hold though).
> > >
> > > I got as far as building initial bare-bones HTML.
> > >
> > > .\gradlew -p solr\solr-ref-guide clean bareBonesHtmlValidation
> > >
> > > I don't know anything about the pipeline involved (asciidoctor, etc.)
> > > so it's very likely some attributes will have to be corrected later
> > > on.
> > >
> > > Dawid
> > >
> > > On Wed, Sep 25, 2019 at 9:14 PM Dawid Weiss  wrote:
> > > >
> > > > I looked at the solr ref guide build and started converting it to
> > > > Gradle but have a question to Mark (because he coordinates the
> > > > effort).
> > > >
> > > > What immediately jumps into face is the decision problem -- do we want
> > > > to emulate what ant does at the moment or do we want to clean it up
> > > > (breaking file/ folder structure and causing incompatibility with ant
> > > > build).
> > > >
> > > > I went the "compatible" way and started porting ant tasks but it's
> > > > quite awkward. For example -- there are template properties that refer
> > > > to ivy version properties... we could emulate/ compute these but it's
> > > > a pain. The way the module is currently structured is also awkward -
> > > > it'd be more natural to have a separate java project with the "tools"
> > > > required to compile extra stuff and just reference it from the manual
> > > > build (and this would be a plain module, not a java module). This
> > > > would limit the need for customizing source sets, classpaths, etc.
> > > >
> > > > My few initial tasks syncing sources, setting up infrastructure to
> > > > filter templates and compiling the required tools are here:
> > > > https://github.com/apache/lucene-solr/compare/jira/SOLR-13452_gradle_7_refguide...dweiss:jira/SOLR-13452_gradle_7_refguide?expand=1
> > > >
> > > > I'll stop and wait for feedback (especially on the ivy versions issue)
> > > > before I resume.
> > > >
> > > > Dawid
> > > >
> > > > On Wed, Sep 25, 2019 at 6:20 PM Dawid Weiss  
> > > > wrote:
> > > > >
> > > > > Never mind, I've got it.
> > > > >
> > > > > D.
> > > > >
> > > > > On Wed, Sep 25, 2019 at 7:59 AM Dawid Weiss  
> > > > > wrote:
> > > > > >
> > > > > > Hi Cassandra,
> > > > > >
> > > > > > > I’m more than happy to share more details our current build so we 
> > > > > > > can replicate some of the above steps, but I’m stuck without a 
> > > > > > > lot more basic Gradle skills that I don’t have time to acquire 
> > > > > > > with day-job/personal life commitments. I put it into a separate 
> > > > > > > branch so we could iterate a little easier, can anyone help?
> > > > > >
> > > > > > Where is this branch you made changes on? If you can point me at the
> > > > > > corresponding ant code I'll try to help you out.
> > > > > >
> > > > > > Dawid
> > >
> > > -
> > > 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: 

Re: The Lucene Solr Gradle Build Game plan

[Cassandra Targett]

I just pushed a new branch for the Ref Guide based off the gradle_7 branch 
(it’s "jira/SOLR-13452_gradle_7_refguide”). I’m completely stuck and try as I 
might I can't get myself unstuck with the time I have.

There are several phases to our current build, and some of these we can drop if 
we drop the PDF build. Just to summarize:

1) All files in solr/solr-ref-guide/src are copied to 
solr/build/solr-ref-guide. The _config.yml.template (used by Jekyll) is 
populated (I think) and copied to plain _config.yml for Jekyll to use.

2) The page hierarchy is built for the left nav and for the previous-next links 
at the bottom of each page. The file list for the PDF is created. The 
bare-bones-html is created to check all the links (unique section ids, javadoc 
links).

3) Jekyll creates the HTML pages and asciidoctor-ant creates the PDF.

I might be missing some nuances there, but that’s the gist. I’ve barely been 
able to recreate this in the branch I created.

I’ve added a task for Jekyll to the build.gradle and am able to get it to 
download the gems (unlike today when you have to download them in advance), but 
the build still fails because it doesn't have all the usual steps of copying 
the dir and fixing the template, etc., but those steps are beyond what I know 
how to do.

It also occurred to me that we could replace some of the Java classes with 
Groovy in the build.gradle itself, but again, I can’t do it.

I’ve also replaced the asciidoctor-ant with asciidoctor-gradle-plugin, but I’m 
not sure how much that’s really getting us if we don’t do the PDF. Supposedly 
the latest versions of that plugin (2.3) allow better gem support, but I 
couldn’t get them to work so I reverted back to 1.6. Someone who knows Gradle 
better might have better luck.

I’m more than happy to share more details our current build so we can replicate 
some of the above steps, but I’m stuck without a lot more basic Gradle skills 
that I don’t have time to acquire with day-job/personal life commitments. I put 
it into a separate branch so we could iterate a little easier, can anyone help?

Cassandra
On Sep 20, 2019, 2:59 PM -0500, Dawid Weiss , wrote:
> I don't want to blow this discussion out of proportion so I'll try to
> make it quick...
>
> > There is convention for this :) The convention is to commit your 
> > gradle.properties and that is what holds your project config. It's widely 
> > done and promoted by the Gradle team.
>
> I disagree with this statement and base my opinion on both my
> experience and what's written in [1]. The gradle.properties file is
> for configuring gradle (and the build's system properties), not for
> configuring project properties and project-related behavior. Even the
> API reflects this distinction (gradle environment vs. the Settings
> object vs. eventual project properties and their inheritance). I'd
> argue that the current setup abuses gradle properties for things that
> could as well be defined elsewhere; ideally as normal project
> properties (however loaded or declared) where they'd be nicely
> propagated to subprojects. But it's cosmetics, fine.
>
> > The daemon is not controlled by us, it's controlled by you and what you put 
> > in your global file.
>
> Exactly. But the versioned gradle.properties has:
>
> org.gradle.daemon=false
>
> If I'd like to work with Lucene with daemon enabled, I'll have to
> change this setting globally (in ~/.gradle.properties). This will
> affect any other Gradle project I have on that machine, which isn't
> too great. Sure, I can set up an environment variable override or even
> a command alias but it's not the point -- it's either a global
> override of this daemon setting or having a dirty checkout. And this
> somehow doesn't feel right to me.
>
> > I would say this: their code to manage this is 1000 times more simple than 
> > the code to do it in randomized testing :)
>
> Well, I strive for perfection but am not hesitant to recognize
> brighter minds (think JUnitBenchmark vs. JMH...).
>
> > For something like testFast (or whatever it's called), first it's super 
> > simple code, second,
>
> Hmm. Did you push these changes? Which branch is this testFast code
> on? I committed a few cleanups to jira/SOLR-13452_gradle_7 -- don't
> know if you saw them.
>
> > This is a big build, there is a lot going on. [... ] so I think it's best 
> > that we devote a JIRA to anything that people feel is important in order to 
> > focus an actionable discussion.
>
> I think it'd be easier to work collectively on that dedicated gradle
> branch, cleaning up stuff and introducing small changes there, but if
> you'd rather have Jira issues or PRs that's up to you -- I asked about
> this but didn't receive a reply.
>
> Dawid
>
> [1] https://docs.gradle.org/current/userguide/build_environment.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: 

Re: Rethinking how we publish the Solr Ref Guide

[Cassandra Targett]

Thanks everyone, by the way, for the encouragement and feedback here.

For next steps, how do folks feel about making the change to stop voting on the 
PDF *now*? Or, I guess, retroactively for 8.2 since that’s not out yet. I could 
push the HTML and make a PDF but announce to the list that from 8.2 forward we 
consider the HTML the main Ref Guide and the PDF is “for convenience” (and 
explain the thinking behind it).

If we want a VOTE on this policy change, I can do that - I feel like we have 
consensus without it, but we could be more formal about it if folks prefer.

For 8.3 we'll see what we can get automated there, but if it’s not ready I’ll 
just do it manually once the RC is out.

I’ll file a Jira for some of the changes I’ll make to the docs for the process, 
etc., and another one for automation ideas.

Cassandra
On Sep 19, 2019, 2:53 PM -0500, Noble Paul , wrote:
> First of all a big thanks to Cassandra to help coordinate and build
> our ref guide to make it professional. It really used to be pathetic
> before you took over
>
> . Yes we need to avoid "creating work" . There should be no need for a
> ref guide release.
>
> +1 for your plan
>
> On Thu, Sep 19, 2019 at 11:57 PM Cassandra Targett
>  wrote:
> >
> > The pages do already have a “Site last generated” date on them at the 
> > bottom. It’s specifically worded that way for a reason.
> >
> > We actually wanted the date the .adoc file was last updated to be in the 
> > footer too, but the problem has always been that a static site generator 
> > always regenerates all pages every time - so every single page, edited or 
> > not, always has the same exact date on it.
> >
> > And, our build works by copying everything under `solr/solr-ref-guide/src` 
> > to `solr/build`, so every file really has a create date and last updated 
> > date that are always the date you do the build. Basically, the files you 
> > see and work with are not actually the same files that get built - we build 
> > from copies that are made at build-time.
> >
> > (That’s all why it says “Site last generated” instead of “Last updated”.)
> >
> > I’m not saying there’s no way to add a last updated date for the underlying 
> > file, it’s just not obvious how to do it so we skipped it.
> >
> > No problem, though, adding a link to Github - that’s actually kind of a 
> > different thing and I’m pretty sure we could do that right now.
> >
> > Cassandra
> > On Sep 19, 2019, 7:07 AM -0500, Anshum Gupta , 
> > wrote:
> >
> > I agree that we should be able to fix mistakes, my only suggestion was that 
> > those mistakes not be non-trivial. But the more I think about it, the more 
> > I feel convinced about just publishing the updates - however, having a time 
> > stamp on when the guide was last updated would be nice to have. Anything 
> > else would require much more effort and I'm not sure it's worth it.
> >
> > On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter  
> > wrote:
> > >
> > >
> > > : > However Anshum does make a good point that users wouldn't know when
> > > : the pages have changed. I think it would be great to have a link on each
> > > : ref-guide page that shows the last modified date and links to the
> > > : history of that page in github
> > >
> > > : Perhaps we could instead provide a single HTML page or HTML table as
> > > : part of or alongside each guide, showing all commits touching the guide
> > > : on that branch after the release. Could probably be baked in as part of
> > > : the release script. Using the release date or git hash for the release,
> > >
> > > Yeah, there are a lot of options we could pursue for generating a
> > > "changes" list as part of an automated build process -- but i would
> > > consider this idea a "nice to have" feature that shouldn't block moving
> > > forward.
> > >
> > > Given 2 options, I would much rather:
> > > a) have the ability to quickly/easily "fix" mistakes/ommisions in
> > > "official X.y ref-guide" on our site and have it automatically republish,
> > > w/o it being immediately obvious to users that a page may have changed
> > > between yesterday and today.
> > > ... over ...
> > > b) *NOT* being able to re-publish at all just for the sake of users
> > > knowing that the (incorrect) content they are reading is consistent
> > > between yesterday and today.
> > >
> > >
> > > -Hoss
> > > http://www.lucidworks.com/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> >
> > --
> > Anshum Gupta
>
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Re: Rethinking how we publish the Solr Ref Guide

[Cassandra Targett]

The pages do already have a “Site last generated” date on them at the bottom. 
It’s specifically worded that way for a reason.

We actually wanted the date the .adoc file was last updated to be in the footer 
too, but the problem has always been that a static site generator always 
regenerates all pages every time - so every single page, edited or not, always 
has the same exact date on it.

And, our build works by copying everything under `solr/solr-ref-guide/src` to 
`solr/build`, so every file really has a create date and last updated date that 
are always the date you do the build. Basically, the files you see and work 
with are not actually the same files that get built - we build from copies that 
are made at build-time.

(That’s all why it says “Site last generated” instead of “Last updated”.)

I’m not saying there’s no way to add a last updated date for the underlying 
file, it’s just not obvious how to do it so we skipped it.

No problem, though, adding a link to Github - that’s actually kind of a 
different thing and I’m pretty sure we could do that right now.

Cassandra
On Sep 19, 2019, 7:07 AM -0500, Anshum Gupta , wrote:
> I agree that we should be able to fix mistakes, my only suggestion was that 
> those mistakes not be non-trivial. But the more I think about it, the more I 
> feel convinced about just publishing the updates - however, having a time 
> stamp on when the guide was last updated would be nice to have. Anything else 
> would require much more effort and I'm not sure it's worth it.
>
> > On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter  
> > wrote:
> > >
> > > : > However Anshum does make a good point that users wouldn't know when
> > > : the pages have changed. I think it would be great to have a link on each
> > > : ref-guide page that shows the last modified date and links to the
> > > : history of that page in github
> > >
> > > : Perhaps we could instead provide a single HTML page or HTML table as
> > > : part of or alongside each guide, showing all commits touching the guide
> > > : on that branch after the release. Could probably be baked in as part of
> > > : the release script. Using the release date or git hash for the release,
> > >
> > > Yeah, there are a lot of options we could pursue for generating a
> > > "changes" list as part of an automated build process -- but i would
> > > consider this idea a "nice to have" feature that shouldn't block moving
> > > forward.
> > >
> > > Given 2 options, I would much rather:
> > >   a) have the ability to quickly/easily "fix" mistakes/ommisions in
> > > "official X.y ref-guide" on our site and have it automatically republish,
> > > w/o it being immediately obvious to users that a page may have changed
> > > between yesterday and today.
> > >       ... over ...
> > >   b) *NOT* being able to re-publish at all just for the sake of users
> > > knowing that the (incorrect) content they are reading is consistent
> > > between yesterday and today.
> > >
> > >
> > > -Hoss
> > > http://www.lucidworks.com/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
>
>
> --
> Anshum Gupta

Re: Moving Lucene web site to git and .asf.yaml

[Cassandra Targett]

Sort of playing devil’s advocate for sake of discussion, why would we pick 
Pelican static site generator over Jekyll static site generator which we 
already use for the Ref Guide? Why would we stay with Markdown when we already 
know that Asciidoc is a much more expressive markup language that we already 
use for hundreds of pages of content?

I know nothing about Pelican - your mail is the first I heard of it - so asking 
that really just as a way to get more info for why you prefer it.

Assuming we move to a world where something like the Ref Guide is simply 
“website content”, I could see it becoming burdensome to generate HTML files 
with 2 different systems in 2 different formats, etc. Is that a valid concern 
or not something you’re worried about?

Cassandra
On Sep 19, 2019, 3:33 AM -0500, Jan Høydahl , wrote:
> Hi all,
>
> INFRA announced a few weeks back a new self-serve mechanism .asf.yaml:
>
> https://s.apache.org/asfyaml
>
> As I understand it, the old forrest CMS built from svn will eventually go away
> and this is the new shiny way to publish (and stage) project websites.
>
> I propose that we start to play with .asf.yaml by first adding the file to 
> change
> our GitHub project description which now says "Mirror of Apache Lucene + 
> Solr" :)
>
> Next let's migrate our web site from the svn over to a new branch in our git 
> repo.
> We could choose to use the Pelican static site generator, and then 
> stage/publish
> the site automatically using .asf.yaml magic. Moving from forrest to Pelican
> (https://blog.getpelican.com) will take some effort, but they are both based 
> on
> markdown and templating so should not be an impossible task :)
>
> A positive site effect of moving our site to git could be that it gets easier 
> to
> dump our JavaDocs, RefGuide, future developer-Guides by simply committing html
> files to the site git branch.
>
> We should also design a new Lucene landing page but that's for another day...
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

Rethinking how we publish the Solr Ref Guide

[Cassandra Targett]

 The delays getting the Ref Guides for 8.x releases out have caused me to
think a bit about the Ref Guide publication process. It seems clear others
aren't able to pick up the process when I can't and I’m sure there are a
million individual reasons for that so I don't intend to shame or blame
anyone, but a process that relies on a single person in a community our
size isn’t a very good one. And, if I think about _why_ we have a process
like we have today [1], I’m not sure it makes a ton of sense any longer.

So, I propose making some radical changes. My ideas here require a shift
from thinking of the Guide as a release artifact like the binaries to
thinking of it similar to how we treat javadocs. These ideas also allow us
to finally get to the goal of unifying these currently separate processes.

1. Make the HTML version the “official” version.
-- What to do with the PDF is TBD after that decision, see below.

2. Stop voting for the Ref Guide release as a separate VOTE thread.

3. Jenkins jobs are already created when a release branch is cut. We can
change these jobs so they always automatically push the HTML version to the
website, although before the version binaries are released the pages would
still have a DRAFT watermark across them [2].
-- By ASF policy, release artifacts must be produced on a machine
controlled by the committer. However, the point here is that the Ref Guide
would no longer be a release artifact, so I think that gets us around that
rule? If anyone sees this differently that would change things here a
little bit.
-- I know other projects have similar Jenkins->publish workflows, but I’m
not sure exactly what’s involved in setting it up. Might need to discuss
with the Infra team and other changes may be required depending.
-- The goal, though, is to automate this as much as possible.

4. When a VOTE has passed, a simple step could be added to the release
process to run a Jenkins job to regenerate the HTML pages without the
current DRAFT watermark and automatically push them to the production
website.
-- Since we usually leave branch jobs configured-but-disabled for a little
bit in case a patch release is necessary, typos or other things fixed
“post-release" could be fixed and the Ref Guide Jenkins job would just push
new commits to the branch to the live production site.
-- These updates would be done without the DRAFT status, since the Ref
Guide in that branch is now considered “live”.
-- This part of the idea would allow us to more easily backport any docs
changes and re-publish the Guide without having to do a new vote, which we
would need today. This might be rare, but it is a question that comes up
from time-to-time. I feel that if the publication process was easier, we
might fix things retroactively more often.

5. Some tooling would be nice to automate parts of the copy edit process I
do today, so it can be run by any committer at any point in the process.
This can follow on later. I have a list.

So, that's the idea in a nutshell - thoughts?

[1] Current release process:
https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
[2] Example of DRAFT watermark (it's all CSS, it could look however we want
it to):
https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-8.x/javadoc/

PS, As for the PDF, I believe there are mixed opinions about it. Some rely
on it, others only use it when they need it (portability, easier to search,
etc.), others don’t ever look at it. The fact is it’s over 1600 pages, and
that’s just really too big. Joel is about to add a significant number of
new images as part of a new "visual" guide (see SOLR-13105), which will
make it even longer and bigger. Trying to split it to make it smaller would
bring in a lot of complexity with how to deal with links between pages that
end up in different PDF files (believe me, I've done it before). And
finally, it holds us back a little - some things we could do with HTML/JS
can't be done in PDF. I’d be fine continuing to produce it, just not as our
main artifact. We could have Jenkins push that also to the SVN dist/dev
repo where it currently lives.

Cassandra

Re: 8.3 release

[Cassandra Targett]

As I’ve mentioned to some of you over the past couple of weeks, I want to 
propose that we don’t “release” the Ref Guide at all the way we have been doing 
it.

It deserves a separate thread, which since it’s come up a few times this week I 
should start now, but in essence, my idea is to no longer treat the PDF as a 
release artifact that requires a vote, and publish the HTML as our primary 
version of the Ref Guide in effectively the same way we publish the javadocs 
(at the same time as the binary artifacts).

Instead of highjacking this thread with that discussion since it has several 
aspects, let me send another mail on it where I can flesh it out more and we 
can discuss there. I have the mail mostly queued up and ready to go already.

Cassandra
On Sep 18, 2019, 10:23 AM -0500, Gus Heck , wrote:
> I learned recently that it's actually all  documented here: 
> https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
>
> > On Tue, Sep 17, 2019 at 7:31 PM Ishan Chattopadhyaya 
> >  wrote:
> > > Hi Adrien,
> > > Indeed, meant to write about starting a vote.
> > >
> > > @Gus, I'll have to let Cassandra weigh in on this one as I'm not very 
> > > familiar with the ref guide release process.
> > >
> > > Regards,
> > > Ishan
> > >
> > > > On Mon, 16 Sep, 2019, 7:28 PM Adrien Grand,  wrote:
> > > > > +1 to start working on 8.3
> > > > >
> > > > > Did you mean "start a vote" when you wrote "release the artifacts"? It
> > > > > got me wondering because I don't think we frequently managed to go
> > > > > from cutting a branch to releasing artifacts in so little time in the
> > > > > past.
> > > > >
> > > > > On Mon, Sep 16, 2019 at 5:52 PM Ishan Chattopadhyaya
> > > > >  wrote:
> > > > > >
> > > > > > Hi all,
> > > > > > We have a lot of unreleased features and fixes. I propose that we 
> > > > > > cut
> > > > > > a 8.3 branch in two weeks (in order to have sufficient time to bake 
> > > > > > in
> > > > > > all in-progress features). If there are no objections to doing so, I
> > > > > > can volunteer for the release as an RM and plan for cutting a 
> > > > > > release
> > > > > > branch on 30 September (and release the artifacts about 3-4 days 
> > > > > > after
> > > > > > that).
> > > > > >
> > > > > > WDYT?
> > > > > > Regards,
> > > > > > Ishan
> > > > > >
> > > > > > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Adrien
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > > >
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

Re: [POLL] Should notifications of NEW Jira issues go to dev@?

[Cassandra Targett]

[v ] Leave it as is - I like quiet

I like the clear separation between the lists. It already feels less 
hectic/overwhelming to me. I will read both as often as I can anyway, so I 
don’t feel I’ll miss anything if the lists stay the way they are now.

There is a Jira plugin to support email digest notifications. I know nothing 
about it, just found it in a quick Google search for Jira notifications. A 
custom bot might be a better solution, but thought I’d point it out in case 
Infra would be willing to install it: 
https://marketplace.atlassian.com/apps/1217383/email-notifications-digest?hosting=server=overview

Thanks for working on these types of improvements!

Cassandra
On Sep 18, 2019, 8:54 AM -0500, Jan Høydahl , wrote:
> Going for a daily digest bot we could clarify this in the email text:
>
> Here is a list of new Lucene/Solr issues created on -MM-DD
>
> LUCENE-NNN  Nice new feature
> SOLR-NNN    Unfortunate bug
>
> To get updates for these issues in the future, watch them in JIRA.
> To get updates for all issues, subscribe to the issues@ mailing list.
>
>
> > 18. sep. 2019 kl. 15:34 skrev Adrien Grand :
> >
> > [x] Leave it as is - I like quiet
> >
> > It's not that much that I like quiet, but rather that I can easily
> > imagine it become confusing over time as new contributors join the
> > list and think they get notified about all interactions on JIRA, only
> > to notice several days later that it only includes notifications about
> > new issues. This behavior can be configured easily enough in email
> > clients.
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>

Re: The Lucene Solr Gradle Build Game plan

[Cassandra Targett]

I got started on the Ref Guide build last night. The biggest change there is to 
use the asciidoctor-gradle-plugin instead of using the asciidoctor-ant plugin.

So far I’ve got it working enough to build a single page of the Ref Guide into 
a PDF file. Baby steps ;)

By itself that only gets us the PDF, while our HTML is built with several Ruby 
gems which we had to require people to install locally. However, the 
asciidoctor-gradle plugin includes JRuby, so fingers crossed we’ll finally be 
able to get that working and end up in a better place than we are today, and 
with a more unified build configuration than we currently have.

I’m not ready to push anything to the branch yet, but hopefully will be in the 
next day or two.

Cassandra
On Sep 17, 2019, 5:02 AM -0500, Dawid Weiss , wrote:
> > [...] last I remember Dawid signed up for it starting around today (15th) ;)
>
> Ah... so you remembered?... Kind of hoped you forgot. :)
>
> I'll take a look and try to tackle some of Chris's questions. Are we
> free to commit to that gradle branch or do you prefer PRs?
>
> D.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

[jira] [Resolved] (SOLR-13714) Incorrect shardHandlerFactory config element documented in refguide for "distributed requests"

[Cassandra Targett (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-13714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett resolved SOLR-13714.
--
Fix Version/s: 8.2
 Assignee: Cassandra Targett
   Resolution: Fixed

> Incorrect shardHandlerFactory config element documented in refguide for 
> "distributed requests"
> --
>
> Key: SOLR-13714
> URL: https://issues.apache.org/jira/browse/SOLR-13714
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.7.2, 8.1.1
>Reporter: Michael Gibney
>Assignee: Cassandra Targett
>Priority: Trivial
> Fix For: 8.2
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Reference guide documentation is inconsistent with respect to configuration 
> of {{shardHandlerFactory}} in {{solrconfig.xml}}.
> The correct config element name is "{{shardHandlerFactory}}", as reflected in 
> code [in 
> SolrXmlConfig.java|https://github.com/apache/lucene-solr/blob/301ea0e/solr/core/src/java/org/apache/solr/core/SolrXmlConfig.java#L460]
>  and [in 
> SearchHandler.java|https://github.com/apache/lucene-solr/blob/43fc05c/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L97].
> The element name is documented correctly in the [refGuide page for "Format of 
> solr.xml"|https://lucene.apache.org/solr/guide/8_1/format-of-solr-xml.html#the-shardhandlerfactory-element],
>  but it is documented incorrectly (as "{{shardHandler}}", not 
> "{{shardHandlerFactory}}" in the [refGuide page for "Distributed 
> Requests"|https://lucene.apache.org/solr/guide/8_1/distributed-requests.html#configuring-the-shardhandlerfactory].



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

Issues with fixVersion = 8.1.2

[Cassandra Targett]

There are 7 resolved/closed issues with the fixVersion 8.1.2. Since that 
version was never released, it’s misleading to leave only a fixVersion that was 
never released. We know we can assume 8.2, but the average user may not.

Shouldn’t these all be changed to 8.2?

Cassandra

[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16909061#comment-16909061
 ] 

Cassandra Targett commented on SOLR-13452:
--

For the docs, there is a plugin for Gradle from the Asciidoctor community 
(https://github.com/asciidoctor/asciidoctor-gradle-plugin), which is (IMO) 
better and more frequently maintained than the one currently we use for Ant. 
That would take care of the PDF. Since we use Jekyll for the HTML version, 
though, that's going to work a little differently and I'll start taking a look 
at what we might need to do there.

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: gradle-build.pdf
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
> https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_5



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13523) Atomic Update results in NullPointerException

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897597#comment-16897597
 ] 

Cassandra Targett commented on SOLR-13523:
--

Since 8.1.2 was never released, should this (and probably others) be updated so 
the fixVersion is 8.2 instead?

> Atomic Update results in NullPointerException
> -
>
> Key: SOLR-13523
> URL: https://issues.apache.org/jira/browse/SOLR-13523
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Affects Versions: 8.1
> Environment: * Operating system: Win10 v1803 build 17143.766
>  * Java version:
> java 11.0.1 2018-10-16 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
>  * solr-spec: 8.1.1
>  * solr-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab - 
> 2019-05-22 15:20:01
>  * lucene-spec: 8.1.1
>  * lucene-impl: 8.1.1 fcbe46c28cef11bc058779afba09521de1b19bef - ab - 
> 2019-05-22 15:15:24
>Reporter: Kieran Devlin
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.1.2
>
> Attachments: SOLR-13523.patch, SOLR-13523.patch, SOLR-13523.patch, 
> SOLR-13523.patch, SOLR-13523_WIP_bug_hunt.patch, XUBrk.png, Xn1RW.png, 
> reproduce.sh
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Partially update a document via an atomic update, when I do so, the web sever 
> responds with a 500 status with the stack trace:
> {code:java}
> { "responseHeader":{ "status":500, "QTime":1}, "error":{ 
> "trace":"java.lang.NullPointerException\r\n\tat 
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.getFieldFromHierarchy(AtomicUpdateDocumentMerger.java:301)\r\n\tat
>  
> org.apache.solr.update.processor.AtomicUpdateDocumentMerger.mergeChildDoc(AtomicUpdateDocumentMerger.java:398)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.getUpdatedDocument(DistributedUpdateProcessor.java:697)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.doVersionAdd(DistributedUpdateProcessor.java:372)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.lambda$versionAdd$0(DistributedUpdateProcessor.java:337)\r\n\tat
>  
> org.apache.solr.update.VersionBucket.runWithLock(VersionBucket.java:50)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:337)\r\n\tat
>  
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:223)\r\n\tat
>  
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)\r\n\tat
>  
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)\r\n\tat
>  
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)\r\n\tat
>  
> org.apache.solr.update.proce

[jira] [Closed] (SOLR-9162) Connection pool shut down

[Cassandra Targett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett closed SOLR-9162.
---

> Connection pool shut down
> -
>
> Key: SOLR-9162
> URL: https://issues.apache.org/jira/browse/SOLR-9162
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Major
>
> We get an "Connection pool shut down""  error  when  upgrading to solr 6.0 ,
> via  solr JDBC
> And here's the exception:
>   2016-05-26 10:41:30.903 b.s.m.n.Server [INFO] Getting metrics for server on 
> port 6700
> 2016-05-26 10:42:13.962 o.a.s.c.S.Request [INFO] 
> [systemTables_shard2_replica1]  webapp=/solr path=/sql 
> params={includeMetadata=true=json=2.2=select+table_name,id+from+systemTables+order+by+id++limit+100=facet}
>  status=0 QTime=1
> 2016-05-26 10:42:13.983 o.a.s.c.s.i.s.ExceptionStream [ERROR] 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: java.lang.IllegalStateException: Connection pool shut 
> down
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.openStreams(CloudSolrStream.java:361)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:243)
>   at 
> org.apache.solr.handler.SQLHandler$LimitStream.open(SQLHandler.java:1265)
>   at 
> org.apache.solr.client.solrj.io.stream.SelectStream.open(SelectStream.java:153)
>   at 
> org.apache.solr.handler.SQLHandler$MetadataStream.open(SQLHandler.java:1511)
>   at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:47)
>   at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:362)
>   at 
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:301)
>   at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
>   at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
>   at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
>   at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
>   at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
>   at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>   at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:399)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty

[jira] [Resolved] (SOLR-9162) Connection pool shut down

[Cassandra Targett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett resolved SOLR-9162.
-
Resolution: Invalid

Closing as this should have gone to solr-user list first.

> Connection pool shut down
> -
>
> Key: SOLR-9162
> URL: https://issues.apache.org/jira/browse/SOLR-9162
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Major
>
> We get an "Connection pool shut down""  error  when  upgrading to solr 6.0 ,
> via  solr JDBC
> And here's the exception:
>   2016-05-26 10:41:30.903 b.s.m.n.Server [INFO] Getting metrics for server on 
> port 6700
> 2016-05-26 10:42:13.962 o.a.s.c.S.Request [INFO] 
> [systemTables_shard2_replica1]  webapp=/solr path=/sql 
> params={includeMetadata=true=json=2.2=select+table_name,id+from+systemTables+order+by+id++limit+100=facet}
>  status=0 QTime=1
> 2016-05-26 10:42:13.983 o.a.s.c.s.i.s.ExceptionStream [ERROR] 
> java.io.IOException: java.util.concurrent.ExecutionException: 
> java.io.IOException: java.lang.IllegalStateException: Connection pool shut 
> down
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.openStreams(CloudSolrStream.java:361)
>   at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:243)
>   at 
> org.apache.solr.handler.SQLHandler$LimitStream.open(SQLHandler.java:1265)
>   at 
> org.apache.solr.client.solrj.io.stream.SelectStream.open(SelectStream.java:153)
>   at 
> org.apache.solr.handler.SQLHandler$MetadataStream.open(SQLHandler.java:1511)
>   at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:47)
>   at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:362)
>   at 
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:301)
>   at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
>   at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
>   at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
>   at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
>   at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
>   at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>   at 
> org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:399)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty

[jira] [Commented] (SOLR-5467) Provide Solr Ref Guide in .epub format

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890171#comment-16890171
 ] 

Cassandra Targett commented on SOLR-5467:
-

Yes, there are asciidoctor tools to convert the .adoc files to ePub: 
https://github.com/asciidoctor/asciidoctor-epub3.

Is there a "need"? Not sure. I've kept this open because I think it would be 
nice to do someday.

> Provide Solr Ref Guide in .epub format
> --
>
> Key: SOLR-5467
> URL: https://issues.apache.org/jira/browse/SOLR-5467
> Project: Solr
>  Issue Type: Wish
>  Components: documentation
>    Reporter: Cassandra Targett
>Priority: Major
>
> From the solr-user list, a request for an .epub version of the Solr Ref Guide.
> There are two possible approaches that immediately come to mind:
> * Ask infra to install a plugin that automatically outputs the Confluence 
> pages in .epub
> * Investigate converting HTML export to .epub with something like calibre
> There might be other options, and there would be additional issues for 
> automating the process of creation and publication, so for now just recording 
> the request with an issue.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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