Re: [Operator] [VOTE] Release the Solr Operator v0.3.0 RC1

That's because helm is annoying and doesn't support the newer version of gpg key files. The smoke test does this for you but you can run this first and it should work: gpg --export >~/.gnupg/pubring.gpg - Houston On Thu, Apr 15, 2021 at 5:23 PM Timothy Potter wrote: > This looks like something

Re: [Operator] [VOTE] Release the Solr Operator v0.3.0 RC1

> > [OK] Verified signatures > [OK] Verified checksums > Thanks for confirming these manually! The smoke test actually does this as well. [BAD] Makefile missing license header > Fair. > [BAD] helm-carts/index.yaml missing licence header > [BAD] most yaml files in source tarball are missing lic

Re: [Operator] [VOTE] Release the Solr Operator v0.3.0 RC1

This looks like something funky with my gnupg setup locally, but I got this: helm install --debug --verify solr-operator solr-operator-rc/solr-operator --set image.tag=v0.3.0-rc1 install.go:172: [debug] Original chart version: "" Error: failed to load keyring: open /Users/tjp/.gnupg/pubring.gpg: n

Re: [Operator] [VOTE] Release the Solr Operator v0.3.0 RC1

-1 [OK] Verified signatures [OK] Verified checksums [BAD] helm-carts/index.yaml missing licence header [BAD] most yaml files in source tarball are missing license headers [BAD] Makefile missing license header [UNKNOWN] what is helm-charts/solr-operator-0.3.0.tgz.prov? It looks like a gpg signed

Re: Use of central git branches

What’s the benefit of using a central branch? It adds cruft in the main repo, and you are able to collaborate very easily via private branches. (Especially if you download the github application) People don't clean up public branches after merging fairly often. On Thu, Apr 15, 2021 at 4:39 PM Ish

Re: Use of central git branches

> Use of central branches is ok for very collaborative work, but 95% of the time it is better with a private branch to avoid extra mailing list traffic etc. How do we know that? On Thu, Apr 15, 2021 at 11:47 PM Jan Høydahl wrote: > Hi, > > Most committers already use a private fork branch for P

Re: [Operator] [VOTE] Release the Solr Operator v0.3.0 RC1

Updated the release wizard, but not my draft email You need to clone the solr-operator repository and checkout the release-0.3 branch before running the smoke test. And you should run the smoke test from the base directory of the solr-operator repo. Hope it goes smoothly for everyone! - Hous

[Operator] [VOTE] Release the Solr Operator v0.3.0 RC1

Please vote for release candidate 1 for the Solr Operator v0.3.0 The artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/solr/solr-operator/solr-operator-v0.3.0-RC1-rev8b14ce2567599561358eaa7d75210cd29fd21a41 You can run the full smoke tester, with instructions below. However

Use of central git branches

Hi, Most committers already use a private fork branch for PRs, and now the list of central branches is getting much tidier than it used to. Use of central branches is ok for very collaborative work, but 95% of the time it is better with a private branch to avoid extra mailing list traffic etc.

Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

Thanks for the reviews, I committed the fix - Solr should now compile again... > 15. apr. 2021 kl. 16:05 skrev Dawid Weiss : > >> We should wait until Lucene 9 is released and then switch to a fixed >> version. This was the plan from beginning and is also fine if it takes more >> months or half

Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

> We should wait until Lucene 9 is released and then switch to a fixed version. > This was the plan from beginning and is also fine if it takes more months or > half a year until Lucene releases 9.0. I think the question was about temporary holds when something in Lucene changes in an incompatib

RE: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

In my personal opinion: We should wait until Lucene 9 is released and then switch to a fixed version. This was the plan from beginning and is also fine if it takes more months or half a year until Lucene releases 9.0. The current behaviour is not bad: If Lucene changes, Jenkins detects a failur

Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

You could ask the infra team what the policy of snapshot retaining is. I see some very old entries here: http://repository.apache.org/content/groups/snapshots/org/apache/lucene/ but 9.0.0-SNAPSHOT only has a few. It's probably the count of releases under a given version (not the age) that matters.

RE: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

Hi, this was done as a first step to preserve the "original Lucene/Solr approach": Make builds fail as soon as possible. The idea was to move away from that definitely in release branches, but keep that snapshot approach in main. We may also think to stick with some fixed artifacts or do some

Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

> You can pin the dependency to a particular snapshot revision... the problem > is those revisions don't stay in snapshot repositories forever Ah, I see. Presumably Solr could avoid this though by copying/republishing the particular snapshot we want our builds to use under the "org.apache.solr"

Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

> Wrt SNAPSHOT, I think we just need to be patient until Lucene releases 9.0.0, > then we can depend on that instead, and choose our own timing for upgrading. You can pin the dependency to a particular snapshot revision... the problem is those revisions don't stay in snapshot repositories forever

Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

Thanks for pointing to that issue Jason, I linked the two as duplicates. My PR is at https://github.com/apache/solr/pull/77 and I think it fixes everything. Wrt SNAPSHOT, I think we just need to be patient until Lucene releases 9.0.0, then we can depend

Re: Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

FYI, Mike Drob filed a separate issue for this yesterday (SOLR-15339). His ticket doesn't have a PR though so maybe that one should be closed as a duplicate? I'm sure this has been discussed previously and I just missed it - but is there a way for us to lock the Solr build on a particular Lucene 9

Solr fails with current lucene-9.0.0-SNAPSHOT (LUCENE-9387)

Due to https://issues.apache.org/jira/browse/LUCENE-9387 being committed, removing some methods in Lucene. Issue https://issues.apache.org/jira/browse/SOLR-15341 to track this. Jan