On Thu, Nov 4, 2021 at 10:42 AM Dawid Weiss wrote:
>
> > we don't have to "support" users on our main trunk branch. That's why
> > we make releases.
>
> Nah. I don't agree with this one - you have to be aware about who is
> using your project (especially a library) and in what context. Maybe
> we
> I think you misunderstood what I said: We still have a stable branch where we
> backport our stuff to. So the main branch is really for "trying out and
> working on new stuff". That's what a main branch is thought for. ...
Sorry if I did. I am definitely mixing up -target and --release - old
w
Thanks Jan!
On Thu, Nov 4, 2021 at 2:32 PM Jan Høydahl wrote:
> I added a PR https://github.com/apache/lucene-solr/pull/2603 for
> SOLR-14438, that I had in the workings. I think it will do...
>
> Jan
>
> 4. nov. 2021 kl. 10:34 skrev Adrien Grand :
>
> Joel recommended not treating SOLR-15762 as
Hi,
> I can imagine some users might like to keep abreast of main, at least
> in some kind of testing setup, but aren't ready to cut over their JDK
> for some reason (as Dawid was describing), but they can always do a
> small patch and build Lucene themselves, applying the -target for
> compatibil
That does not work. You can set -release or -target, but not both with
incompatible variants.
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
From: David Smiley
Sent: Thursday, November 4, 2021 12:44 PM
To: lucene-dev
Subject: Re: Bu
Hello Lucene Developers,
We're working on a search service which uses lucene indexes. One of the things
I'm hoping to find is different places where we can plug in our custom classes
during the search process.
This first use case is for highlighting. The legacy search engine we use
collects all
> we don't have to "support" users on our main trunk branch. That's why
> we make releases.
Nah. I don't agree with this one - you have to be aware about who is
using your project (especially a library) and in what context. Maybe
we differ in our opinion here. Your previous argument is much more
c
we don't have to "support" users on our main trunk branch. That's why
we make releases.
On Thu, Nov 4, 2021 at 9:59 AM Michael Sokolov wrote:
>
> I can imagine some users might like to keep abreast of main, at least
> in some kind of testing setup, but aren't ready to cut over their JDK
> for som
I can imagine some users might like to keep abreast of main, at least
in some kind of testing setup, but aren't ready to cut over their JDK
for some reason (as Dawid was describing), but they can always do a
small patch and build Lucene themselves, applying the -target for
compatibility with their
Fair enough. That test has more problems as the nightly worst-case is just
a total killer time-wise... I really think it should have a wall-clock
expiration deadline inside too.
Dawid
On Thu, Nov 4, 2021 at 2:26 PM Robert Muir wrote:
> On Thu, Nov 4, 2021 at 9:17 AM Dawid Weiss wrote:
> >
> >
I added a PR https://github.com/apache/lucene-solr/pull/2603 for SOLR-14438,
that I had in the workings. I think it will do...
Jan
> 4. nov. 2021 kl. 10:34 skrev Adrien Grand :
>
> Joel recommended not treating SOLR-15762 as a blocker, so we are left with
> the following issues as blockers:
>
On Thu, Nov 4, 2021 at 9:17 AM Dawid Weiss wrote:
>
> I think there should be a better solution based on throttling. This test runs
> with 4 threads - I can imagine processes where an order of magnitude more
> threads will index in parallel (+ merges). So it should just work. I don't
> know how
I think there should be a better solution based on throttling. This test
runs with 4 threads - I can imagine processes where an order of magnitude
more threads will index in parallel (+ merges). So it should just work. I
don't know how to fix it though it's causing additional noise for me when I
sc
With the current release frequency, JDK 11 will be EOL by the time
Lucene 10 is released.
Users can use lucene 9 if they want to stay on old outdated JDKs.
On Thu, Nov 4, 2021 at 7:44 AM David Smiley wrote:
>
> I prefer that we require JDK 17 for build/test but allow our artifacts
> (except luc
Hopefully we can find a better long-term fix for this test?
If fixing IndexWriter throttling is too tricky, maybe we could simply
improve the test with a short-term fix to use less handles (e.g. force
NRTCachingDir or RAMDir)
2048 is already way too high, the default OS limit is 1024 on every
linu
I prefer that we require JDK 17 for build/test but allow our artifacts
(except lucene-test-framework maybe) to be run on JDK 11 (or 14?) via
setting the "target". This allows us some time to appreciate some of the
benefits of Java/JDK 17 without insisting that our users switch. This
approach does
Hi,
I agree with this plan, lets go to JDK17 in Lucene 10 (main), but whenever a
new Java version comes out, update Gradle and the –release=XX switch. Plain
simple! The stable branch has a defined java version (currently “11”), “main”
should be always latest. I don’t think this is a problem,
Joel recommended not treating SOLR-15762 as a blocker, so we are left with
the following issues as blockers:
- SOLR-15706, which should hopefully be addressed soon.
- SOLR-14438, which hasn't had activity for a long time. Is someone
looking into it? Can someone comment on whether it should actual
Now you're talking.
+1.
On Thu, Nov 4, 2021 at 1:49 AM Robert Muir wrote:
> On Wed, Nov 3, 2021 at 1:36 PM Dawid Weiss wrote:
> >
> > I principally agree with you - we should leverage new Java features and
> I'm all for it. I just don't see much difference between
> > Java 11 and 17 in the con
19 matches
Mail list logo
