Re: Change solr/lucene Readme file format

Hey guys, I have created a PR on this, please have a look to see if that's helpful. Thanks: Pinkesh Sharma On Sun, Nov 10, 2019 at 11:29 AM Uwe Schindler wrote: > Hi, > > When building the documentation (ant documentation), all readme files >

Re: Solr Gradle build (SOLR-13452)

OK, so I went ahead and added my changes to make parallel license directories for the nonce (Lucene and Solr). Dawid: If you’d like to see if this now breaks for you like it did for me, feel free ;). It works for me _AFTER_ I replaced the line in the top level versions.props file (this is what

Re: Solr Gradle build (SOLR-13452)

It looks like it’ll be very difficult to have the “jar checksum” stuff work seamlessly between Ant and Gradle, they tend to overwrite each other resulting in a zillion changes depending on which one you ran last. I see three options: 1> tell people NOT to run the Gradle jarChecksums. I doubt

Re: Solr Gradle build (SOLR-13452)

Anshum et. al. : It’s been a busy day, never got back to it. I’ll try to push my changes, mostly updating the dependencies tonight. It’s not ready to merge into master yet, there’s this problem: ant -Dtestcase=TestKoreanTokenizer test fails with: java.lang.RuntimeException: Cannot find

Re: Solr Gradle build (SOLR-13452)

Hey Erick, Any updates on this? Just checking in and though I'm not a gradle guru, I'd be happy to help as much as I can :) -Anshum On Tue, Nov 12, 2019 at 7:32 PM Erick Erickson wrote: > Final note before I turn in. “ant -Dtestcase=TestKoreanTokenizer” fails > OOB on the gradle_8 branch

Re: Do we want to pursue an LTS designation?

: The term LTS is used loosely and we actually do not promise anything. What we say is : : > 7.7.x Version in the previous major release for bugfixes only (LTS) ... : Being the one coining the LTS phrasing I am not opposed to changing it : to something else. But through the

Re: ReleaseWizard tool

Ishan, do you have some feedback on the ReleaseWizard? Also I notice that the redirect to the latest refGuide is not changed on the website, so e.g https://lucene.apache.org/solr/guide/distributed-requests.html redirects to 8_2

Re: Do we want to pursue an LTS designation?

The term LTS is used loosely and we actually do not promise anything. What we say is > 7.7.x Version in the previous major release for bugfixes only (LTS) In practice 7.7.x will now only get critical security related releases and not ordinary bugfixes, unless someone volunteers to RM such a

Re: Do we want to pursue an LTS designation?

It looks like solr 7.7.x is currently designated as the LTS version on the website. https://lucene.apache.org/solr/downloads.html On Wed, Nov 13, 2019 at 11:36 AM Erick Erickson wrote: > I have zero interest in having an LTS “policy” that requires any further > commitment of my personal time to

Re: Do we want to pursue an LTS designation?

I have zero interest in having an LTS “policy” that requires any further commitment of my personal time to random people who ask for it but aren’t willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, not something anyone has a right to demand as “support”, long-term or

Propose Solr committer meeting next week

I am proposing a virtual "Solr committer meeting" next week to discuss the concerns and ideas Mark Miller has raised recently. The scope of conversation of this one is not the other wonderful things people are working on (e.g. new plugins architecture), though I would *love* to have future

Do we want to pursue an LTS designation?

We've had somebody on the Solr mailing list asking questions about our LTS version. The thing about this is that we don't really HAVE an LTS version. Our major version release pace and the way we deal with older branches mean that a single major version branch is never in a given state for

Re: asciidoctor in gradle build

NP, I’m just grateful it’s more than just me working on it ;) > On Nov 13, 2019, at 8:50 AM, Cassandra Targett wrote: > > 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

Re: asciidoctor in gradle build

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

Re: asciidoctor in gradle build

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

Re: asciidoctor in gradle build

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

Re: asciidoctor in gradle build

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

Re: Solr Gradle build (SOLR-13452)

I would really like you help out but you seem special. ;) Is your checkout clean (git clean -xfd .), do you have any locally modified files (git status)? I just ran ./gradlew jarChecksums on two different machines (Windows, Linux) and everything passed, look: :~/work-ssd/lucene-solr$ ./gradlew