Re: Communicating the future of DIH?

[Mike Drob]

I'm somewhat unclear - is the suggestion to submit projects to Apache
Commons repositories or to do a similar process with our own multiple
repositories.

On Tue, Nov 3, 2020 at 2:43 PM Gézapeti  wrote:

> I'm not that close with Apache Commons either, but I think the
> solr-operator is a perfect candidate to figure out how things should work.
> I'd be happy to do some exploration and reach out to other projects about
> their experience in this matter.
> gp
>
>
> On Tue, Nov 3, 2020 at 9:31 PM David Smiley  wrote:
>
>> Thanks Gezapeti for recommending that model.  It makes sense to me
>> conceptually... yet it seems burdensome, at least to set it up (website,
>> lists, repos, misc.) and get us familiar with a new way of working.  I have
>> nothing but questions about how they operate.  As it is, we haven't even
>> done our TLP split yet, which is maybe a little embarrassing as a PMC
>> member.  I wonder if other ASF projects do anything similar for their
>> plugins?  I'd guess Maven or Ant might be similar.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Wed, Oct 28, 2020 at 2:12 PM Gézapeti Cseh 
>> wrote:
>>
>>> Hey everyone,
>>>
>>> Solr could keep some plugins with separate git repositories under the
>>> Apache umbrella if it adapts the Apache Commons model
>>> where plugins can have their own release
>>> schedule and community without the risk of being abandoned completely
>>> without notice. There is a process to get into Apache Commons via the
>>> sandbox  and to end development
>>> in dormant .
>>> I know this solution would still add the load of vulnerabilities and
>>> releases to the Apache Solr project, but components/plugins could have a
>>> level of separation while keeping the trust in ASF behind the plugins.
>>> Also, if a vulnerability surfaces for a particular plugin/component not the
>>> whole Solr release would be marked as affected.
>>> I'm not saying we should do this with DataImportHandler, but I think. it
>>> worth considering for other plugins.
>>>
>>> I'm not sure if this was discussed before, I've tried to search the
>>> archives without any luck.
>>> gp
>>>
>>>
>>>
>>> On Thu, Oct 15, 2020 at 11:35 PM Anshum Gupta 
>>> wrote:
>>>
 I think that the fact that this code is no longer under the Apache
 umbrella will lead to such issues and moving this into a different GitHub
 org wouldn't really help with the problem that's been highlighted. Also,
 the maintainers of a plugin should be people who understand and monitor the
 project and if those rights are opened up, it'd be hard to maintain
 reliability of the plugin.

 Thanks for updating the Ref Guide, Cassandra :) In line with my
 suggestion above, I think we need to be clear with the messaging of the
 fact that the code no longer is owned and maintained by the Apache
 Lucene/Solr community and any vulnerability or bug reported in the 3rd
 party packages wouldn't be the responsibility of the Apache Lucene
 community.


 On Thu, Oct 15, 2020 at 2:16 PM Cassandra Targett <
 casstarg...@gmail.com> 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 

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

Re: Communicating the future of DIH?

[Gézapeti]

I'm not that close with Apache Commons either, but I think the
solr-operator is a perfect candidate to figure out how things should work.
I'd be happy to do some exploration and reach out to other projects about
their experience in this matter.
gp


On Tue, Nov 3, 2020 at 9:31 PM David Smiley  wrote:

> Thanks Gezapeti for recommending that model.  It makes sense to me
> conceptually... yet it seems burdensome, at least to set it up (website,
> lists, repos, misc.) and get us familiar with a new way of working.  I have
> nothing but questions about how they operate.  As it is, we haven't even
> done our TLP split yet, which is maybe a little embarrassing as a PMC
> member.  I wonder if other ASF projects do anything similar for their
> plugins?  I'd guess Maven or Ant might be similar.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Oct 28, 2020 at 2:12 PM Gézapeti Cseh  wrote:
>
>> Hey everyone,
>>
>> Solr could keep some plugins with separate git repositories under the
>> Apache umbrella if it adapts the Apache Commons model
>> where plugins can have their own release
>> schedule and community without the risk of being abandoned completely
>> without notice. There is a process to get into Apache Commons via the
>> sandbox  and to end development
>> in dormant .
>> I know this solution would still add the load of vulnerabilities and
>> releases to the Apache Solr project, but components/plugins could have a
>> level of separation while keeping the trust in ASF behind the plugins.
>> Also, if a vulnerability surfaces for a particular plugin/component not the
>> whole Solr release would be marked as affected.
>> I'm not saying we should do this with DataImportHandler, but I think. it
>> worth considering for other plugins.
>>
>> I'm not sure if this was discussed before, I've tried to search the
>> archives without any luck.
>> gp
>>
>>
>>
>> On Thu, Oct 15, 2020 at 11:35 PM Anshum Gupta 
>> wrote:
>>
>>> I think that the fact that this code is no longer under the Apache
>>> umbrella will lead to such issues and moving this into a different GitHub
>>> org wouldn't really help with the problem that's been highlighted. Also,
>>> the maintainers of a plugin should be people who understand and monitor the
>>> project and if those rights are opened up, it'd be hard to maintain
>>> reliability of the plugin.
>>>
>>> Thanks for updating the Ref Guide, Cassandra :) In line with my
>>> suggestion above, I think we need to be clear with the messaging of the
>>> fact that the code no longer is owned and maintained by the Apache
>>> Lucene/Solr community and any vulnerability or bug reported in the 3rd
>>> party packages wouldn't be the responsibility of the Apache Lucene
>>> community.
>>>
>>>
>>> On Thu, Oct 15, 2020 at 2: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 

Re: Communicating the future of DIH?

[David Smiley]

Thanks Gezapeti for recommending that model.  It makes sense to me
conceptually... yet it seems burdensome, at least to set it up (website,
lists, repos, misc.) and get us familiar with a new way of working.  I have
nothing but questions about how they operate.  As it is, we haven't even
done our TLP split yet, which is maybe a little embarrassing as a PMC
member.  I wonder if other ASF projects do anything similar for their
plugins?  I'd guess Maven or Ant might be similar.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Oct 28, 2020 at 2:12 PM Gézapeti Cseh  wrote:

> Hey everyone,
>
> Solr could keep some plugins with separate git repositories under the
> Apache umbrella if it adapts the Apache Commons model
> where plugins can have their own release
> schedule and community without the risk of being abandoned completely
> without notice. There is a process to get into Apache Commons via the
> sandbox  and to end development
> in dormant .
> I know this solution would still add the load of vulnerabilities and
> releases to the Apache Solr project, but components/plugins could have a
> level of separation while keeping the trust in ASF behind the plugins.
> Also, if a vulnerability surfaces for a particular plugin/component not the
> whole Solr release would be marked as affected.
> I'm not saying we should do this with DataImportHandler, but I think. it
> worth considering for other plugins.
>
> I'm not sure if this was discussed before, I've tried to search the
> archives without any luck.
> gp
>
>
>
> On Thu, Oct 15, 2020 at 11:35 PM Anshum Gupta 
> wrote:
>
>> I think that the fact that this code is no longer under the Apache
>> umbrella will lead to such issues and moving this into a different GitHub
>> org wouldn't really help with the problem that's been highlighted. Also,
>> the maintainers of a plugin should be people who understand and monitor the
>> project and if those rights are opened up, it'd be hard to maintain
>> reliability of the plugin.
>>
>> Thanks for updating the Ref Guide, Cassandra :) In line with my
>> suggestion above, I think we need to be clear with the messaging of the
>> fact that the code no longer is owned and maintained by the Apache
>> Lucene/Solr community and any vulnerability or bug reported in the 3rd
>> party packages wouldn't be the responsibility of the Apache Lucene
>> community.
>>
>>
>> On Thu, Oct 15, 2020 at 2: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 

Re: Maintaining Unnecessary Test Files

[David Smiley]

On Tue, Nov 3, 2020 at 1:50 PM Marcus Eagan  wrote:

> @David Smiley  It would seem to me that
> TestSpatialFilter would be fine with no mention of the port in the name.
> It's a confusing identifier.
>

Feel free to propose a better name and file a PR.  It's lineage (origins
from Solr) is however useful information that should stay as a comment.


> As for TestGeo3dShapeWGS84ModelRectRelation, there are lots of comments.
>
> Not sure what the value of this comment is in the class
>
>  /*
>  [junit4]   1> S-R Rel: {}, Shape {}, Rectangle {}lap# {} [CONTAINS, 
> Geo3dShape{planetmodel=PlanetModel: {xyScaling=1.0011188180710464, 
> zScaling=0.9977622539852008}, shape=GeoPath: {planetmodel=PlanetModel: 
> {xyScaling=1.0011188180710464, zScaling=0.9977622539852008}, 
> width=1.53588974175501(87.99),
>   points={[[X=0.12097657665150223, Y=-0.6754177666095532, 
> Z=0.7265376136709238], [X=-0.3837892785614207, Y=0.4258049113530899, 
> Z=0.8180007850434892]]}}},
>   Rect(minX=4.0,maxX=36.0,minY=16.0,maxY=16.0), 6981](no slf4j subst; sorry)
>  [junit4] FAILURE 0.59s | Geo3dWGS84ShapeRectRelationTest.testGeoPathRect <<<
>  [junit4]> Throwable #1: java.lang.AssertionError: 
> Geo3dShape{planetmodel=PlanetModel: {xyScaling=1.0011188180710464, 
> zScaling=0.9977622539852008}, shape=GeoPath: {planetmodel=PlanetModel: 
> {xyScaling=1.0011188180710464, zScaling=0.9977622539852008}, 
> width=1.53588974175501(87.99),
>   points={[[X=0.12097657665150223, Y=-0.6754177666095532, 
> Z=0.7265376136709238], [X=-0.3837892785614207, Y=0.4258049113530899, 
> Z=0.8180007850434892]]}}} intersect Pt(x=23.81626064835212,y=16.0)
>  [junit4]>  at 
> __randomizedtesting.SeedInfo.seed([2595268DA3F13FEA:6CC30D8C83453E5D]:0)
>  [junit4]>  at 
> org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
>  [junit4]>  at 
> org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
>  [junit4]>  at 
> org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:128)
>  [junit4]>  at 
> org.apache.lucene.spatial.spatial4j.Geo3dWGS84ShapeRectRelationTest.testGeoPathRect(Geo3dWGS84ShapeRectRelationTest.java:265)
> */
>
> That shows log/error output of the failure that was ultimately fixed.


> This comment either. It just seems like these are stream of conscious notes 
> and maybe they should be captured in the relevant tickets, which could be 
> referenced. Do you think it should be in the actual source code?
>
> // Rectangle contains point
> //assertTrue(rect.isWithin(pt));
> // Path contains point (THIS FAILS)
> //assertTrue(path.isWithin(pt));
> // What happens: (1) The center point of the horizontal line is within the 
> path, in fact within a radius of one of the endpoints.
> // (2) The point mentioned is NOT inside either SegmentEndpoint.
> // (3) The point mentioned is NOT inside the path segment, either.  (I think 
> it should be...)
>
>
> I suppose... I'm not sure 5 years later.

Re: Maintaining Unnecessary Test Files

[Marcus Eagan]

@David Smiley  It would seem to me that
TestSpatialFilter would be fine with no mention of the port in the name.
It's a confusing identifier.

As for TestGeo3dShapeWGS84ModelRectRelation, there are lots of comments.

Not sure what the value of this comment is in the class

 /*
 [junit4]   1> S-R Rel: {}, Shape {}, Rectangle {}lap# {}
[CONTAINS, Geo3dShape{planetmodel=PlanetModel:
{xyScaling=1.0011188180710464, zScaling=0.9977622539852008},
shape=GeoPath: {planetmodel=PlanetModel:
{xyScaling=1.0011188180710464, zScaling=0.9977622539852008},
width=1.53588974175501(87.99),
  points={[[X=0.12097657665150223, Y=-0.6754177666095532,
Z=0.7265376136709238], [X=-0.3837892785614207, Y=0.4258049113530899,
Z=0.8180007850434892]]}}},
  Rect(minX=4.0,maxX=36.0,minY=16.0,maxY=16.0), 6981](no slf4j subst; sorry)
 [junit4] FAILURE 0.59s | Geo3dWGS84ShapeRectRelationTest.testGeoPathRect <<<
 [junit4]> Throwable #1: java.lang.AssertionError:
Geo3dShape{planetmodel=PlanetModel: {xyScaling=1.0011188180710464,
zScaling=0.9977622539852008}, shape=GeoPath: {planetmodel=PlanetModel:
{xyScaling=1.0011188180710464, zScaling=0.9977622539852008},
width=1.53588974175501(87.99),
  points={[[X=0.12097657665150223, Y=-0.6754177666095532,
Z=0.7265376136709238], [X=-0.3837892785614207, Y=0.4258049113530899,
Z=0.8180007850434892]]}}} intersect Pt(x=23.81626064835212,y=16.0)
 [junit4]>  at
__randomizedtesting.SeedInfo.seed([2595268DA3F13FEA:6CC30D8C83453E5D]:0)
 [junit4]>  at
org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase._assertIntersect(RandomizedShapeTestCase.java:168)
 [junit4]>  at
org.apache.lucene.spatial.spatial4j.RandomizedShapeTestCase.assertRelation(RandomizedShapeTestCase.java:153)
 [junit4]>  at
org.apache.lucene.spatial.spatial4j.RectIntersectionTestHelper.testRelateWithRectangle(RectIntersectionTestHelper.java:128)
 [junit4]>  at
org.apache.lucene.spatial.spatial4j.Geo3dWGS84ShapeRectRelationTest.testGeoPathRect(Geo3dWGS84ShapeRectRelationTest.java:265)
*/

This comment either. It just seems like these are stream of conscious
notes and maybe they should be captured in the relevant tickets, which
could be referenced. Do you think it should be in the actual source
code?

// Rectangle contains point
//assertTrue(rect.isWithin(pt));
// Path contains point (THIS FAILS)
//assertTrue(path.isWithin(pt));
// What happens: (1) The center point of the horizontal line is within
the path, in fact within a radius of one of the endpoints.
// (2) The point mentioned is NOT inside either SegmentEndpoint.
// (3) The point mentioned is NOT inside the path segment, either.  (I
think it should be...)




On Mon, Nov 2, 2020 at 7:00 AM David Smiley  wrote:

> Hi Marcus,
>
> PortSolr3Test is documented "Based off of Solr 3's SpatialFilterTest".
> Why do you propose removing it?  A quick gloss over it suggests to me this
> test is a rather straight-forward test to understand and maintain, and
> should be fast.  Perhaps the class name should have been something else,
> and consider it's heritage as an implementation detail that is only worthy
> of a comment?  But then name it what?  IMO it's fine.
>
> TestGeo3dShapeWGS84ModelRectRelation: What about it?  This test class is
> 99% implemented by it's subclass -- ShapeRectRelationTestCase.  The
> subclass provides the Geo3d context to its superclass, and the rest is
> handled from there.  The tests explicitly on this subclass are for some
> regressions.
>
> > Is there anyone keeping a list of test cases that we can get rid of  or
> significantly refactor today?
>
> For Solr -- yes (sorta): SOLR-11872
> .  That would be a
> major make-over, but wouldn't really change the number of tests; it'd make
> them easier to maintain and more flexible.  There is another issue, 
> SOLR-10229,
> pertaining to Solr tests ought to configure Solr themselves and rely less
> on static test config files, which are a mess to maintain.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Nov 1, 2020 at 5:21 PM Marcus Eagan  wrote:
>
>> Hi Community,
>>
>> Lately I have been reading a lot of test files in an attempt to
>> understand what they seek to accomplish. Specifically, what stability and
>> reliability assurance does a given test class provide. In short, I have
>> found some test files that I am unsure are required to provide any of the
>> expected guarantees of the project today.
>>
>> It is more possible that I am misreading or don’t know all the history to
>> opine, and I don’t want to waste anyone’s time with a ticket without first
>> raising a discussion here. Below, I’ll include a few examples from Lucene.
>> As of today, I fully intend to step through many of the test files from
>> Solr as well for a related effort, but I started with Lucene because I have
>> ~800 more classes in Solr to review/modify/flag for review and because
>> there is 

Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 699 - Still Failing!

[Dawid Weiss]

I corrected sandbox class name reference that was the problem here.

Dawid

On Tue, Nov 3, 2020 at 2:39 PM Apache Jenkins Server
 wrote:
>
> Build: 
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/699/
>
> All tests passed
>
> Build Log:
> [...truncated 1619 lines...]
> BUILD FAILED in 1h 6m 1s
> 852 actionable tasks: 852 executed
> Build step 'Invoke Gradle script' changed build result to FAILURE
> Build step 'Invoke Gradle script' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
> -
> 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

Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 698 - Failure!

[Dawid Weiss]

These randomized test failures reproduce for me in this test.

Dawid

On Tue, Nov 3, 2020 at 8:30 AM Apache Jenkins Server
 wrote:
>
> Build: 
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/698/
>
> 1 tests failed.
> FAILED:  org.apache.solr.TestRandomDVFaceting.testRandomFaceting
>
> Error Message:
> java.lang.AssertionError: mismatch: 'LJAC'!='EKYL' @ 
> facet_counts/facet_fields/id/[2]
>
> Stack Trace:
> java.lang.AssertionError: mismatch: 'LJAC'!='EKYL' @ 
> facet_counts/facet_fields/id/[2]
> at 
> __randomizedtesting.SeedInfo.seed([B758812B355044AA:BA30A1FE60A98C15]:0)
> at org.junit.Assert.fail(Assert.java:89)
> at 
> org.apache.solr.TestRandomDVFaceting.doFacetTests(TestRandomDVFaceting.java:292)
> at 
> org.apache.solr.TestRandomDVFaceting.doFacetTests(TestRandomDVFaceting.java:175)
> at 
> org.apache.solr.TestRandomDVFaceting.testRandomFaceting(TestRandomDVFaceting.java:158)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at 
>