Article link at Lucene FAQ does not exist anymore

[Michael Wechner]

Hi

The QnA

https://cwiki.apache.org/confluence/display/lucene/lucenefaq#LuceneFAQ-HowcanIindexXMLdocuments?

is pointing to (See also this article Parsing, indexing, and searching 
XML with Digester and Lucene 
.)


http://www-106.ibm.com/developerworks/library/j-lucene/

but this does not seem to exist anymore and one gets redirected to

https://developer.ibm.com/

I have found an old copy from 2003

https://web.archive.org/web/20030608074955/http://www-106.ibm.com/developerworks/library/j-lucene/

but I guess it does not really make sense to still link this, right?

Thanks

Michael

Re: Anyone familiar (or use) MultiRangeQuery?

[Michael Sokolov]

I did a little git spelunking and found this PR
https://github.com/apache/lucene-solr/pull/794 where it was
introduced. It does sound to me as if the intent was to match on
multiple multi-dimensional ranges (ie hypercubes), not on any
dimension among multiple ranges? Why would anyone ever want to do
that? On the other hand a lot of people looked at it ... so maybe
we're missing something here?

On Sun, Nov 21, 2021 at 11:14 AM Greg Miller  wrote:
>
> Hi folks-
>
> Is anyone familiar with MultiRangeQuery (found in
> o.a.l.sandbox.search)? I was playing around with it recently since it
> might be a good fit for a use-case I'm working on for Amazon's Product
> Search engine, but it looks like it has a pretty fundamental bug in
> how it works. That or I'm completely mis-understanding what the query
> is meant to do.
>
> My understanding is that this query should consider documents to be a
> match if they contain a point that is found in _any_ of the ranges
> represented by this query (i.e., it's a disjunction over a set of
> query ranges). But... it appears that the query incorrectly considers
> a document to be a match if its point matches on any single dimension
> of any range (where it should be requiring all dimensions in a
> particular range to match).
>
> I added a unit test to demonstrate this bug along with a proposed fix
> over here: https://github.com/apache/lucene/pull/437
>
> If anyone is familiar with this query (or better yet, uses it), I'd be
> really interested in your input.
>
> Cheers,
> -Greg
>
> -
> 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: What should we do of branch_8x?

[Jan Høydahl]

+1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be 
an 8.12 release by Lucene PMC.

Whether Solr needs to release an 8.12 from own repos or not can be discussed in 
dev@solr if/when needed. So far there is only loose talk, and I think Solr 
PMC's energy should be devoted to the Solr 9.0 release.

Jan

> 22. nov. 2021 kl. 08:28 skrev Atri Sharma :
> 
> +1, agree with Uwe.
> 
> On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
>  wrote:
>> 
>> +1 to Uwe's suggestion
>> 
>> On Mon, 22 Nov, 2021, 11:13 am Gus Heck,  wrote:
>>> 
>>> +1 to uwe's suggestion
>>> 
>>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul  wrote:
 
 I think this is a reasonable suggestion Uwe.
 
 - We don't need to bring Gradle to 8.x
 - We can release 8.12 from a fork of 8.11.
 - we don't need to keep the Lucene source files in that branch. We can 
 nuke it and just keep the Lucene binaries
 
 On Mon, Nov 22, 2021, 8:49 AM Uwe Schindler  wrote:
> 
> Hi,
> 
> If this is really needed, I'd propose the following:
> 
> - fork the branch_8_11 to solr's repo
> - delete all subdirectories below lucene, keep common-build and other 
> stuff.
> - add a single ivy.xml there that refers to all lucene jars of 8.11.x 
> (latest)
> - adapt solr's "copy-lucene-jars" ant task to copy the ivy output dir
> - delete the lucene stuff from release wizard.
> 
> This is quick and easy. Adapting Gradle for a minor release is too hard.
> 
> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul 
> :
>> 
>> All Solr users using 8x and they will need some time to get comfortable 
>> with 9x . So, there is a good chance we may need to release an 8.12 
>> based on Lucene 8.11
>> 
>> On Mon, Nov 22, 2021, 8:22 AM Adrien Grand  wrote:
>>> 
>>> +1 to making branch_8x read-only as Uwe suggested
>>> 
>>> I think Uwe's other point is also important: if we ever wanted to do a 
>>> Solr 8.12, it'd probably be a better option to fork the 8.11 branch 
>>> than to try to reuse branch_8x. So we don't need to tie the decision 
>>> about what we want to do with branch_8x with future plans around an 
>>> 8.12 release?
>>> 
>>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
 
 This is of course all possible, but: WHY the heck do this?
 
 
 
 Lucene 9.0 will come out likely very soon. After that just update the 
 gradle file of Solr main and remove the temporary repository (better 
 comment it out). After that adapt some changes and release Solr 9.0.
 
 
 
 From that point on both projects have a clear split point and 
 everybody can make sure that the backwards compatibility is handled 
 according to project’s needs.
 
 
 
 If the Solr 9.0 release is a intermediary point (not all deprecations 
 removed), release Solr 10.0 four months later, who cares? Solr 9.0 
 will be the release with many new features and Java 11 as minimum 
 requirement.
 
 
 
 I would really, really not start and fuck up the release process for 
 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to 
 do? Why do this release needs to be called 8.12? It is just a version 
 number, so why the heck this big issues? I won’t think that Solr will 
 add any major features before Solr 9. So what is your exact problem?
 
 
 
 Sorry, but this discussion is complete nonsense. Its just version 
 numbers and some hick-hack between two parties that disagree. Keep 
 calm and don’t try to make it overcomplicated!
 
 
 
 I never said that we should kill or delete branch_8x. It can stay 
 there forever. I just suggested to make it read-only and add a note. 
 Unless there’s really a need to do some 8.12 release (in which case, 
 I’d fork 8.11 branch and move Lucene) I see no reason to act and fuck 
 up the repositories of both projects which have now a very clear state.
 
 
 
 Uwe
 
 
 
 -
 
 Uwe Schindler
 
 Achterdiek 19, D-28357 Bremen
 
 https://www.thetaphi.de
 
 eMail: u...@thetaphi.de
 
 
 
 From: Gus Heck 
 Sent: Sunday, November 21, 2021 5:05 PM
 To: dev 
 Subject: Re: What should we do of branch_8x?
 
 
 
 Release of Solr 8.12 It should require the current lucene-solr 8.x 
 branch to remove the lucene bits and declare a dependency on lucene 
 8.11 lucene, that bit shouldn't be too hard if done soon... and the 
 release process for 

Re: [VOTE] Release Lucene 9.0.0 RC1

[Tomoko Uchida]

Ok, thank you. I backported it to branch_9_0.

Tomoko

2021年11月22日(月) 21:29 Adrien Grand :
>
> Agreed, I'll respin.
> Tomoko, can you backport your fix to branch_9_0?
>
> Le lun. 22 nov. 2021 à 12:42, Dawid Weiss  a écrit :
>>
>> This is my copy/paste mistake - I work with Unixish shells all the
>> time but rarely with a user interface and didn't have a chance to
>> check. Let's see if anything else pops up but this is definitely worth
>> a respin in my opinion as it's one of the fundamental reasons for the
>> binary release to exist...
>>
>> Dawid
>>
>> On Mon, Nov 22, 2021 at 12:05 PM Tomoko Uchida
>>  wrote:
>> >
>> > SUCCESS! [0:25:27.340580]
>> >
>> > I noticed the Luke start script for *nix does not work and pushed a
>> > fix [1] on main and branch_9x. The launch script for Windows works
>> > well.
>> > I am fine with the release candidate - it is a minor shell script bug
>> > and I think users can easily make a patch - but wanted to give notice
>> > of that, just in case.
>> >
>> > [1] 
>> > https://github.com/apache/lucene/commit/4193bcbc02313c82afcf8cf9e2d14e47466cb1c3
>> >
>> > Tomoko
>> >
>> > 2021年11月22日(月) 6:18 Adrien Grand :
>> > >
>> > > Fair enough. I don't think this requires respinning so what I'll do is 
>> > > that I'll keep the vote thread open until we have a resolution on the 
>> > > issue.
>> > >
>> > > On Sun, Nov 21, 2021 at 1:29 PM Robert Muir  wrote:
>> > >>
>> > >> and yes, I think it is reasonable to be a blocker. If we release 9.0,
>> > >> promising 2 major versions of back compat, some of these options get
>> > >> removed from the table.
>> > >>
>> > >> On Sun, Nov 21, 2021 at 7:23 AM Robert Muir  wrote:
>> > >> >
>> > >> > Thanks Ignacio,
>> > >> >
>> > >> > I see several choices, but the status quo of the testing is the 
>> > >> > problem.
>> > >> >
>> > >> > One choice is to not make any technical changes, but do something to
>> > >> > prevent lucene from having to be compatible with 20 different versions
>> > >> > :) For example, not supporting 2 major versions back would cut it in
>> > >> > half. Another solution would be to release major versions faster so
>> > >> > that we churn thru the versions at a more sustainable rate rather than
>> > >> > having them pile up.
>> > >> >
>> > >> > Another option is to technically alter how the testing is done (as
>> > >> > suggested on the issue). It could mean that some of them only run
>> > >> > nightly or otherwise in jenkins. Which exact tests? I'm not sure, just
>> > >> > as long as it becomes reasonable.
>> > >> >
>> > >> > On Sun, Nov 21, 2021 at 7:18 AM Ignacio Vera  
>> > >> > wrote:
>> > >> > >
>> > >> > > Your issue has not been ignored but the problem is that the version 
>> > >> > > of the blocker has not been added so it doesn't appear in a search 
>> > >> > > for blockers in Lucene 9 :(
>> > >> > >
>> > >> > > Do we need to discuss this again? I thought we discussed and agreed 
>> > >> > > on increasing our backwards compatibility. My personal opinion is 
>> > >> > > that it is a natural step for mature software that it is 
>> > >> > > increasingly used in production environments.
>> > >> > >
>> > >> > > Regarding your concerns in the subject, there is a healthy 
>> > >> > > discussion in the issue and there are sound proposals to ease the 
>> > >> > > pain and they can be implemented any time, do you think it is still 
>> > >> > > a blocker?
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > On Sun, Nov 21, 2021 at 12:59 PM Robert Muir  
>> > >> > > wrote:
>> > >> > >>
>> > >> > >> Along the same lines of back compat woes, I'd like to see my 
>> > >> > >> blocker
>> > >> > >> issue about back compat testing addressed in the release candidate,
>> > >> > >> rather than simply ignored.
>> > >> > >>
>> > >> > >> https://issues.apache.org/jira/browse/LUCENE-10168
>> > >> > >>
>> > >> > >> With the 9.0 release, we are attempting to *double* our backwards
>> > >> > >> compatibility guarantees (2 major versions), yet here we are
>> > >> > >> discussing insane release strategies that can't be 
>> > >> > >> guaranteed/tested
>> > >> > >> to work (8.12-after-9.0-etc), here we are with back compat tests
>> > >> > >> taking a minute and half on branch_9_0! Imagine how long they will
>> > >> > >> take for branch_9_9!
>> > >> > >>
>> > >> > >> When it comes to more back compat, people are quick to demand more 
>> > >> > >> of
>> > >> > >> it every time. But when it comes to addressing the necessary 
>> > >> > >> issues to
>> > >> > >> make it work...crickets.
>> > >> > >>
>> > >> > >> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  
>> > >> > >> wrote:
>> > >> > >> >
>> > >> > >> > -1 to release lucene 9.0, as long as branch_8x remains.
>> > >> > >> >
>> > >> > >> > I know you made a separate thread for this, but it is a real 
>> > >> > >> > problem.
>> > >> > >> >
>> > >> > >> > The problem is that we can't support backwards compatibility like
>> > >> > >> > this: releasing 9.0 then 8.12's and stuff. It isn't how the back
>> > >> > 

Re: [VOTE] Release Lucene 9.0.0 RC1

[Adrien Grand]

Agreed, I'll respin.
Tomoko, can you backport your fix to branch_9_0?

Le lun. 22 nov. 2021 à 12:42, Dawid Weiss  a écrit :

> This is my copy/paste mistake - I work with Unixish shells all the
> time but rarely with a user interface and didn't have a chance to
> check. Let's see if anything else pops up but this is definitely worth
> a respin in my opinion as it's one of the fundamental reasons for the
> binary release to exist...
>
> Dawid
>
> On Mon, Nov 22, 2021 at 12:05 PM Tomoko Uchida
>  wrote:
> >
> > SUCCESS! [0:25:27.340580]
> >
> > I noticed the Luke start script for *nix does not work and pushed a
> > fix [1] on main and branch_9x. The launch script for Windows works
> > well.
> > I am fine with the release candidate - it is a minor shell script bug
> > and I think users can easily make a patch - but wanted to give notice
> > of that, just in case.
> >
> > [1]
> https://github.com/apache/lucene/commit/4193bcbc02313c82afcf8cf9e2d14e47466cb1c3
> >
> > Tomoko
> >
> > 2021年11月22日(月) 6:18 Adrien Grand :
> > >
> > > Fair enough. I don't think this requires respinning so what I'll do is
> that I'll keep the vote thread open until we have a resolution on the issue.
> > >
> > > On Sun, Nov 21, 2021 at 1:29 PM Robert Muir  wrote:
> > >>
> > >> and yes, I think it is reasonable to be a blocker. If we release 9.0,
> > >> promising 2 major versions of back compat, some of these options get
> > >> removed from the table.
> > >>
> > >> On Sun, Nov 21, 2021 at 7:23 AM Robert Muir  wrote:
> > >> >
> > >> > Thanks Ignacio,
> > >> >
> > >> > I see several choices, but the status quo of the testing is the
> problem.
> > >> >
> > >> > One choice is to not make any technical changes, but do something to
> > >> > prevent lucene from having to be compatible with 20 different
> versions
> > >> > :) For example, not supporting 2 major versions back would cut it in
> > >> > half. Another solution would be to release major versions faster so
> > >> > that we churn thru the versions at a more sustainable rate rather
> than
> > >> > having them pile up.
> > >> >
> > >> > Another option is to technically alter how the testing is done (as
> > >> > suggested on the issue). It could mean that some of them only run
> > >> > nightly or otherwise in jenkins. Which exact tests? I'm not sure,
> just
> > >> > as long as it becomes reasonable.
> > >> >
> > >> > On Sun, Nov 21, 2021 at 7:18 AM Ignacio Vera 
> wrote:
> > >> > >
> > >> > > Your issue has not been ignored but the problem is that the
> version of the blocker has not been added so it doesn't appear in a search
> for blockers in Lucene 9 :(
> > >> > >
> > >> > > Do we need to discuss this again? I thought we discussed and
> agreed on increasing our backwards compatibility. My personal opinion is
> that it is a natural step for mature software that it is increasingly used
> in production environments.
> > >> > >
> > >> > > Regarding your concerns in the subject, there is a healthy
> discussion in the issue and there are sound proposals to ease the pain and
> they can be implemented any time, do you think it is still a blocker?
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Sun, Nov 21, 2021 at 12:59 PM Robert Muir 
> wrote:
> > >> > >>
> > >> > >> Along the same lines of back compat woes, I'd like to see my
> blocker
> > >> > >> issue about back compat testing addressed in the release
> candidate,
> > >> > >> rather than simply ignored.
> > >> > >>
> > >> > >> https://issues.apache.org/jira/browse/LUCENE-10168
> > >> > >>
> > >> > >> With the 9.0 release, we are attempting to *double* our backwards
> > >> > >> compatibility guarantees (2 major versions), yet here we are
> > >> > >> discussing insane release strategies that can't be
> guaranteed/tested
> > >> > >> to work (8.12-after-9.0-etc), here we are with back compat tests
> > >> > >> taking a minute and half on branch_9_0! Imagine how long they
> will
> > >> > >> take for branch_9_9!
> > >> > >>
> > >> > >> When it comes to more back compat, people are quick to demand
> more of
> > >> > >> it every time. But when it comes to addressing the necessary
> issues to
> > >> > >> make it work...crickets.
> > >> > >>
> > >> > >> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir 
> wrote:
> > >> > >> >
> > >> > >> > -1 to release lucene 9.0, as long as branch_8x remains.
> > >> > >> >
> > >> > >> > I know you made a separate thread for this, but it is a real
> problem.
> > >> > >> >
> > >> > >> > The problem is that we can't support backwards compatibility
> like
> > >> > >> > this: releasing 9.0 then 8.12's and stuff. It isn't how the
> back
> > >> > >> > compat testing works, it is completely cowboy and unsupported.
> > >> > >> >
> > >> > >> > On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand <
> jpou...@gmail.com> wrote:
> > >> > >> > >
> > >> > >> > > I think we should remove it but I remember it was
> controversial in the past. I'll start a separate thread.
> > >> > >> > >
> > >> > >> > > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler 
> 

Re: [VOTE] Release Lucene 9.0.0 RC1

[Dawid Weiss]

This is my copy/paste mistake - I work with Unixish shells all the
time but rarely with a user interface and didn't have a chance to
check. Let's see if anything else pops up but this is definitely worth
a respin in my opinion as it's one of the fundamental reasons for the
binary release to exist...

Dawid

On Mon, Nov 22, 2021 at 12:05 PM Tomoko Uchida
 wrote:
>
> SUCCESS! [0:25:27.340580]
>
> I noticed the Luke start script for *nix does not work and pushed a
> fix [1] on main and branch_9x. The launch script for Windows works
> well.
> I am fine with the release candidate - it is a minor shell script bug
> and I think users can easily make a patch - but wanted to give notice
> of that, just in case.
>
> [1] 
> https://github.com/apache/lucene/commit/4193bcbc02313c82afcf8cf9e2d14e47466cb1c3
>
> Tomoko
>
> 2021年11月22日(月) 6:18 Adrien Grand :
> >
> > Fair enough. I don't think this requires respinning so what I'll do is that 
> > I'll keep the vote thread open until we have a resolution on the issue.
> >
> > On Sun, Nov 21, 2021 at 1:29 PM Robert Muir  wrote:
> >>
> >> and yes, I think it is reasonable to be a blocker. If we release 9.0,
> >> promising 2 major versions of back compat, some of these options get
> >> removed from the table.
> >>
> >> On Sun, Nov 21, 2021 at 7:23 AM Robert Muir  wrote:
> >> >
> >> > Thanks Ignacio,
> >> >
> >> > I see several choices, but the status quo of the testing is the problem.
> >> >
> >> > One choice is to not make any technical changes, but do something to
> >> > prevent lucene from having to be compatible with 20 different versions
> >> > :) For example, not supporting 2 major versions back would cut it in
> >> > half. Another solution would be to release major versions faster so
> >> > that we churn thru the versions at a more sustainable rate rather than
> >> > having them pile up.
> >> >
> >> > Another option is to technically alter how the testing is done (as
> >> > suggested on the issue). It could mean that some of them only run
> >> > nightly or otherwise in jenkins. Which exact tests? I'm not sure, just
> >> > as long as it becomes reasonable.
> >> >
> >> > On Sun, Nov 21, 2021 at 7:18 AM Ignacio Vera  wrote:
> >> > >
> >> > > Your issue has not been ignored but the problem is that the version of 
> >> > > the blocker has not been added so it doesn't appear in a search for 
> >> > > blockers in Lucene 9 :(
> >> > >
> >> > > Do we need to discuss this again? I thought we discussed and agreed on 
> >> > > increasing our backwards compatibility. My personal opinion is that it 
> >> > > is a natural step for mature software that it is increasingly used in 
> >> > > production environments.
> >> > >
> >> > > Regarding your concerns in the subject, there is a healthy discussion 
> >> > > in the issue and there are sound proposals to ease the pain and they 
> >> > > can be implemented any time, do you think it is still a blocker?
> >> > >
> >> > >
> >> > >
> >> > > On Sun, Nov 21, 2021 at 12:59 PM Robert Muir  wrote:
> >> > >>
> >> > >> Along the same lines of back compat woes, I'd like to see my blocker
> >> > >> issue about back compat testing addressed in the release candidate,
> >> > >> rather than simply ignored.
> >> > >>
> >> > >> https://issues.apache.org/jira/browse/LUCENE-10168
> >> > >>
> >> > >> With the 9.0 release, we are attempting to *double* our backwards
> >> > >> compatibility guarantees (2 major versions), yet here we are
> >> > >> discussing insane release strategies that can't be guaranteed/tested
> >> > >> to work (8.12-after-9.0-etc), here we are with back compat tests
> >> > >> taking a minute and half on branch_9_0! Imagine how long they will
> >> > >> take for branch_9_9!
> >> > >>
> >> > >> When it comes to more back compat, people are quick to demand more of
> >> > >> it every time. But when it comes to addressing the necessary issues to
> >> > >> make it work...crickets.
> >> > >>
> >> > >> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  wrote:
> >> > >> >
> >> > >> > -1 to release lucene 9.0, as long as branch_8x remains.
> >> > >> >
> >> > >> > I know you made a separate thread for this, but it is a real 
> >> > >> > problem.
> >> > >> >
> >> > >> > The problem is that we can't support backwards compatibility like
> >> > >> > this: releasing 9.0 then 8.12's and stuff. It isn't how the back
> >> > >> > compat testing works, it is completely cowboy and unsupported.
> >> > >> >
> >> > >> > On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand  
> >> > >> > wrote:
> >> > >> > >
> >> > >> > > I think we should remove it but I remember it was controversial 
> >> > >> > > in the past. I'll start a separate thread.
> >> > >> > >
> >> > >> > > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a 
> >> > >> > > écrit :
> >> > >> > >>
> >> > >> > >> Yes. But we won't have a 8.12 release so I assume the branch_8x 
> >> > >> > >> is dead. Maybe we should dass a note to it's readme or delete it?
> >> > >> > >>
> >> > >> > >> Uwe
> >> > >> > >>
> >> > >> > >> Am 20. 

Re: [VOTE] Release Lucene 9.0.0 RC1

[Tomoko Uchida]

SUCCESS! [0:25:27.340580]

I noticed the Luke start script for *nix does not work and pushed a
fix [1] on main and branch_9x. The launch script for Windows works
well.
I am fine with the release candidate - it is a minor shell script bug
and I think users can easily make a patch - but wanted to give notice
of that, just in case.

[1] 
https://github.com/apache/lucene/commit/4193bcbc02313c82afcf8cf9e2d14e47466cb1c3

Tomoko

2021年11月22日(月) 6:18 Adrien Grand :
>
> Fair enough. I don't think this requires respinning so what I'll do is that 
> I'll keep the vote thread open until we have a resolution on the issue.
>
> On Sun, Nov 21, 2021 at 1:29 PM Robert Muir  wrote:
>>
>> and yes, I think it is reasonable to be a blocker. If we release 9.0,
>> promising 2 major versions of back compat, some of these options get
>> removed from the table.
>>
>> On Sun, Nov 21, 2021 at 7:23 AM Robert Muir  wrote:
>> >
>> > Thanks Ignacio,
>> >
>> > I see several choices, but the status quo of the testing is the problem.
>> >
>> > One choice is to not make any technical changes, but do something to
>> > prevent lucene from having to be compatible with 20 different versions
>> > :) For example, not supporting 2 major versions back would cut it in
>> > half. Another solution would be to release major versions faster so
>> > that we churn thru the versions at a more sustainable rate rather than
>> > having them pile up.
>> >
>> > Another option is to technically alter how the testing is done (as
>> > suggested on the issue). It could mean that some of them only run
>> > nightly or otherwise in jenkins. Which exact tests? I'm not sure, just
>> > as long as it becomes reasonable.
>> >
>> > On Sun, Nov 21, 2021 at 7:18 AM Ignacio Vera  wrote:
>> > >
>> > > Your issue has not been ignored but the problem is that the version of 
>> > > the blocker has not been added so it doesn't appear in a search for 
>> > > blockers in Lucene 9 :(
>> > >
>> > > Do we need to discuss this again? I thought we discussed and agreed on 
>> > > increasing our backwards compatibility. My personal opinion is that it 
>> > > is a natural step for mature software that it is increasingly used in 
>> > > production environments.
>> > >
>> > > Regarding your concerns in the subject, there is a healthy discussion in 
>> > > the issue and there are sound proposals to ease the pain and they can be 
>> > > implemented any time, do you think it is still a blocker?
>> > >
>> > >
>> > >
>> > > On Sun, Nov 21, 2021 at 12:59 PM Robert Muir  wrote:
>> > >>
>> > >> Along the same lines of back compat woes, I'd like to see my blocker
>> > >> issue about back compat testing addressed in the release candidate,
>> > >> rather than simply ignored.
>> > >>
>> > >> https://issues.apache.org/jira/browse/LUCENE-10168
>> > >>
>> > >> With the 9.0 release, we are attempting to *double* our backwards
>> > >> compatibility guarantees (2 major versions), yet here we are
>> > >> discussing insane release strategies that can't be guaranteed/tested
>> > >> to work (8.12-after-9.0-etc), here we are with back compat tests
>> > >> taking a minute and half on branch_9_0! Imagine how long they will
>> > >> take for branch_9_9!
>> > >>
>> > >> When it comes to more back compat, people are quick to demand more of
>> > >> it every time. But when it comes to addressing the necessary issues to
>> > >> make it work...crickets.
>> > >>
>> > >> On Sun, Nov 21, 2021 at 5:11 AM Robert Muir  wrote:
>> > >> >
>> > >> > -1 to release lucene 9.0, as long as branch_8x remains.
>> > >> >
>> > >> > I know you made a separate thread for this, but it is a real problem.
>> > >> >
>> > >> > The problem is that we can't support backwards compatibility like
>> > >> > this: releasing 9.0 then 8.12's and stuff. It isn't how the back
>> > >> > compat testing works, it is completely cowboy and unsupported.
>> > >> >
>> > >> > On Sat, Nov 20, 2021 at 9:19 AM Adrien Grand  
>> > >> > wrote:
>> > >> > >
>> > >> > > I think we should remove it but I remember it was controversial in 
>> > >> > > the past. I'll start a separate thread.
>> > >> > >
>> > >> > > Le sam. 20 nov. 2021 à 14:38, Uwe Schindler  a 
>> > >> > > écrit :
>> > >> > >>
>> > >> > >> Yes. But we won't have a 8.12 release so I assume the branch_8x is 
>> > >> > >> dead. Maybe we should dass a note to it's readme or delete it?
>> > >> > >>
>> > >> > >> Uwe
>> > >> > >>
>> > >> > >> Am 20. November 2021 13:15:23 UTC schrieb Adrien Grand 
>> > >> > >> :
>> > >> > >>>
>> > >> > >>> We need to keep the 8.11 jobs, but I think they can be disabled. 
>> > >> > >>> We typically only enable them when we start discussing doing a 
>> > >> > >>> new patch release?
>> > >> > >>>
>> > >> > >>> Le sam. 20 nov. 2021 à 12:51, Uwe Schindler  a 
>> > >> > >>> écrit :
>> > >> > 
>> > >> >  Hi,
>> > >> > 
>> > >> >  I setup my usual release tester job on Policeman Jenkins and it 
>> > >> >  succeeded:
>> > >> >  SUCCESS! [0:19:00.801641]
>> > >> > 
>> > 

Re: [JENKINS-EA] Lucene-main-Linux (64bit/jdk-18-ea+24) - Build # 31759 - Failure!

[Dawid Weiss]

Temporary glitch, it seems (http 503 on downloading gradle wrapper).

On Mon, Nov 22, 2021 at 7:21 AM Policeman Jenkins Server
 wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-main-Linux/31759/
> Java: 64bit/jdk-18-ea+24 -XX:+UseCompressedOops -XX:+UseParallelGC
>
> No tests ran.
>
> -
> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
> For additional commands, e-mail: builds-h...@lucene.apache.org

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