Re: BadApple

[Ishan Chattopadhyaya]

Thanks Erick. I've fixed the package manager tests.

On Mon, 18 Nov, 2019, 9:58 PM Erick Erickson, 
wrote:

> Short form:
>
> Holding reasonably steady, except:
>
> PackageManagerCLITest.testPackeageManager is failing over 50% of the time.
>
> MoverReplicaHDFSTest.test failing over 40% of the time.
>
> TestFstDirectAddressing.testDeDupeTails is failing 18% of the time.
>
> Full output attached:
>
>
> There were 154 unannotated tests that failed in Hoss' rollups. Ordered by
> the date I downloaded the rollup file, newest->oldest. See above for the
> dates the files were collected
> These tests were NOT BadApple'd or AwaitsFix'd
> All tests that failed 4 weeks running will be BadApple'd unless there are
> objections
>
> Failures in the last 4 reports..
>Report   Pct runsfails   test
>  0123   3.3  917 45  BasicAuthIntegrationTest.testBasicAuth
>  0123   0.5  943  7
> DimensionalRoutedAliasUpdateProcessorTest.testCatTime
>  0123   2.7  943 18
> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat
>  0123   8.3  961 91
> LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
>  0123  43.8  202 85  MoveReplicaHDFSTest.test
>  0123   0.5  903  5
> ReindexCollectionTest.testSameTargetReindexing
>  0123   4.8  104  5
> ShardSplitTest.testSplitWithChaosMonkey
>  0123   0.5  918  9
> SystemCollectionCompatTest.testBackCompat
>  0123   4.8  941 52
> TestCloudSearcherWarming.testRepFactor1LeaderStartup
>  0123   2.7  946 77
> TestModelManagerPersistence.testFilePersistence
>  0123   2.2  940 70
> TestModelManagerPersistence.testWrapperModelPersistence
>  0123   1.6  921 19
> TestSkipOverseerOperations.testSkipLeaderOperations
>  0123   0.6  905 11  TestStressLiveNodes.testStress
>  0123   1.1  651  9  TestTlogReplica.testKillTlogReplica
>  0123   4.2  112 11
> TestXYMultiPolygonShapeQueries.testRandomBig
>  Will BadApple all tests above this line except ones listed at
> the top**
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

Re: BadApple

[Chris Hostetter]

: I ran TestFstDirectAddressing.testDeDupeTails > 100 times with no
: failure, both on master and on branch_8x (on an Ubuntu w/a couple of
: different JDKs). Can you tell which branch/jvm/os is seeing the
: failures for that test? I couldn't tell from the attached report.

it's already been addressed - by you - in LUCENE-8920  (Erick's note was 
about it's overall success rate for the past 7 days)



: 
: On Mon, Nov 18, 2019 at 11:28 AM Erick Erickson  
wrote:
: >
: > Short form:
: >
: > Holding reasonably steady, except:
: >
: > PackageManagerCLITest.testPackeageManager is failing over 50% of the time.
: >
: > MoverReplicaHDFSTest.test failing over 40% of the time.
: >
: > TestFstDirectAddressing.testDeDupeTails is failing 18% of the time.
: >
: > Full output attached:
: >
: >
: > There were 154 unannotated tests that failed in Hoss' rollups. Ordered by 
the date I downloaded the rollup file, newest->oldest. See above for the dates 
the files were collected
: > These tests were NOT BadApple'd or AwaitsFix'd
: > All tests that failed 4 weeks running will be BadApple'd unless there are 
objections
: >
: > Failures in the last 4 reports..
: >Report   Pct runsfails   test
: >  0123   3.3  917 45  BasicAuthIntegrationTest.testBasicAuth
: >  0123   0.5  943  7  
DimensionalRoutedAliasUpdateProcessorTest.testCatTime
: >  0123   2.7  943 18  
DimensionalRoutedAliasUpdateProcessorTest.testTimeCat
: >  0123   8.3  961 91  
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
: >  0123  43.8  202 85  MoveReplicaHDFSTest.test
: >  0123   0.5  903  5  
ReindexCollectionTest.testSameTargetReindexing
: >  0123   4.8  104  5  ShardSplitTest.testSplitWithChaosMonkey
: >  0123   0.5  918  9  
SystemCollectionCompatTest.testBackCompat
: >  0123   4.8  941 52  
TestCloudSearcherWarming.testRepFactor1LeaderStartup
: >  0123   2.7  946 77  
TestModelManagerPersistence.testFilePersistence
: >  0123   2.2  940 70  
TestModelManagerPersistence.testWrapperModelPersistence
: >  0123   1.6  921 19  
TestSkipOverseerOperations.testSkipLeaderOperations
: >  0123   0.6  905 11  TestStressLiveNodes.testStress
: >  0123   1.1  651  9  TestTlogReplica.testKillTlogReplica
: >  0123   4.2  112 11  
TestXYMultiPolygonShapeQueries.testRandomBig
: >  Will BadApple all tests above this line except ones listed at 
the top**
: >
: >
: > -
: > 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
: 
: 

-Hoss
http://www.lucidworks.com/

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

Re: BadApple

[Michael Sokolov]

Perhaps the failures were reported prior to the recent fix?
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=359864c

On Mon, Nov 18, 2019 at 5:15 PM Michael Sokolov  wrote:
>
> I ran TestFstDirectAddressing.testDeDupeTails > 100 times with no
> failure, both on master and on branch_8x (on an Ubuntu w/a couple of
> different JDKs). Can you tell which branch/jvm/os is seeing the
> failures for that test? I couldn't tell from the attached report.
>
> On Mon, Nov 18, 2019 at 11:28 AM Erick Erickson  
> wrote:
> >
> > Short form:
> >
> > Holding reasonably steady, except:
> >
> > PackageManagerCLITest.testPackeageManager is failing over 50% of the time.
> >
> > MoverReplicaHDFSTest.test failing over 40% of the time.
> >
> > TestFstDirectAddressing.testDeDupeTails is failing 18% of the time.
> >
> > Full output attached:
> >
> >
> > There were 154 unannotated tests that failed in Hoss' rollups. Ordered by 
> > the date I downloaded the rollup file, newest->oldest. See above for the 
> > dates the files were collected
> > These tests were NOT BadApple'd or AwaitsFix'd
> > All tests that failed 4 weeks running will be BadApple'd unless there are 
> > objections
> >
> > Failures in the last 4 reports..
> >Report   Pct runsfails   test
> >  0123   3.3  917 45  BasicAuthIntegrationTest.testBasicAuth
> >  0123   0.5  943  7  
> > DimensionalRoutedAliasUpdateProcessorTest.testCatTime
> >  0123   2.7  943 18  
> > DimensionalRoutedAliasUpdateProcessorTest.testTimeCat
> >  0123   8.3  961 91  
> > LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
> >  0123  43.8  202 85  MoveReplicaHDFSTest.test
> >  0123   0.5  903  5  
> > ReindexCollectionTest.testSameTargetReindexing
> >  0123   4.8  104  5  ShardSplitTest.testSplitWithChaosMonkey
> >  0123   0.5  918  9  
> > SystemCollectionCompatTest.testBackCompat
> >  0123   4.8  941 52  
> > TestCloudSearcherWarming.testRepFactor1LeaderStartup
> >  0123   2.7  946 77  
> > TestModelManagerPersistence.testFilePersistence
> >  0123   2.2  940 70  
> > TestModelManagerPersistence.testWrapperModelPersistence
> >  0123   1.6  921 19  
> > TestSkipOverseerOperations.testSkipLeaderOperations
> >  0123   0.6  905 11  TestStressLiveNodes.testStress
> >  0123   1.1  651  9  TestTlogReplica.testKillTlogReplica
> >  0123   4.2  112 11  
> > TestXYMultiPolygonShapeQueries.testRandomBig
> >  Will BadApple all tests above this line except ones listed at 
> > the top**
> >
> >
> > -
> > 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: BadApple

[Michael Sokolov]

I ran TestFstDirectAddressing.testDeDupeTails > 100 times with no
failure, both on master and on branch_8x (on an Ubuntu w/a couple of
different JDKs). Can you tell which branch/jvm/os is seeing the
failures for that test? I couldn't tell from the attached report.

On Mon, Nov 18, 2019 at 11:28 AM Erick Erickson  wrote:
>
> Short form:
>
> Holding reasonably steady, except:
>
> PackageManagerCLITest.testPackeageManager is failing over 50% of the time.
>
> MoverReplicaHDFSTest.test failing over 40% of the time.
>
> TestFstDirectAddressing.testDeDupeTails is failing 18% of the time.
>
> Full output attached:
>
>
> There were 154 unannotated tests that failed in Hoss' rollups. Ordered by the 
> date I downloaded the rollup file, newest->oldest. See above for the dates 
> the files were collected
> These tests were NOT BadApple'd or AwaitsFix'd
> All tests that failed 4 weeks running will be BadApple'd unless there are 
> objections
>
> Failures in the last 4 reports..
>Report   Pct runsfails   test
>  0123   3.3  917 45  BasicAuthIntegrationTest.testBasicAuth
>  0123   0.5  943  7  
> DimensionalRoutedAliasUpdateProcessorTest.testCatTime
>  0123   2.7  943 18  
> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat
>  0123   8.3  961 91  
> LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
>  0123  43.8  202 85  MoveReplicaHDFSTest.test
>  0123   0.5  903  5  
> ReindexCollectionTest.testSameTargetReindexing
>  0123   4.8  104  5  ShardSplitTest.testSplitWithChaosMonkey
>  0123   0.5  918  9  SystemCollectionCompatTest.testBackCompat
>  0123   4.8  941 52  
> TestCloudSearcherWarming.testRepFactor1LeaderStartup
>  0123   2.7  946 77  
> TestModelManagerPersistence.testFilePersistence
>  0123   2.2  940 70  
> TestModelManagerPersistence.testWrapperModelPersistence
>  0123   1.6  921 19  
> TestSkipOverseerOperations.testSkipLeaderOperations
>  0123   0.6  905 11  TestStressLiveNodes.testStress
>  0123   1.1  651  9  TestTlogReplica.testKillTlogReplica
>  0123   4.2  112 11  
> TestXYMultiPolygonShapeQueries.testRandomBig
>  Will BadApple all tests above this line except ones listed at 
> the top**
>
>
> -
> 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: BadApple

[Tomás Fernández Löbbe]

I’ve been working with TestTlogReplica, please don’t change that one

On Mon, Nov 18, 2019 at 8:28 AM Erick Erickson 
wrote:

> Short form:
>
> Holding reasonably steady, except:
>
> PackageManagerCLITest.testPackeageManager is failing over 50% of the time.
>
> MoverReplicaHDFSTest.test failing over 40% of the time.
>
> TestFstDirectAddressing.testDeDupeTails is failing 18% of the time.
>
> Full output attached:
>
>
> There were 154 unannotated tests that failed in Hoss' rollups. Ordered by
> the date I downloaded the rollup file, newest->oldest. See above for the
> dates the files were collected
> These tests were NOT BadApple'd or AwaitsFix'd
> All tests that failed 4 weeks running will be BadApple'd unless there are
> objections
>
> Failures in the last 4 reports..
>Report   Pct runsfails   test
>  0123   3.3  917 45  BasicAuthIntegrationTest.testBasicAuth
>  0123   0.5  943  7
> DimensionalRoutedAliasUpdateProcessorTest.testCatTime
>  0123   2.7  943 18
> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat
>  0123   8.3  961 91
> LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
>  0123  43.8  202 85  MoveReplicaHDFSTest.test
>  0123   0.5  903  5
> ReindexCollectionTest.testSameTargetReindexing
>  0123   4.8  104  5
> ShardSplitTest.testSplitWithChaosMonkey
>  0123   0.5  918  9
> SystemCollectionCompatTest.testBackCompat
>  0123   4.8  941 52
> TestCloudSearcherWarming.testRepFactor1LeaderStartup
>  0123   2.7  946 77
> TestModelManagerPersistence.testFilePersistence
>  0123   2.2  940 70
> TestModelManagerPersistence.testWrapperModelPersistence
>  0123   1.6  921 19
> TestSkipOverseerOperations.testSkipLeaderOperations
>  0123   0.6  905 11  TestStressLiveNodes.testStress
>  0123   1.1  651  9  TestTlogReplica.testKillTlogReplica
>  0123   4.2  112 11
> TestXYMultiPolygonShapeQueries.testRandomBig
>  Will BadApple all tests above this line except ones listed at
> the top**
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Propose Solr committer meeting next week

[Erick Erickson]

No problem in deferring the Gradle discussion. I’m getting into it a little 
deeper so I’ll know more about how close it is to prime-time as time passes..

> On Nov 18, 2019, at 11:04 AM, Mike Drob  wrote:
> 
> What's the medium for this? Is somebody going to make a 
> webex/zoom/meet/whatever link? I'd like to make sure I have the right tools 
> installed and will do my best to join from airport wifi.
> 
> On Mon, Nov 18, 2019 at 2:49 AM Jan Høydahl  wrote:
> I view Jörn’s SIP proposal as a way for tighter gate keeping of future major 
> changes, helping maintain hard fought stability and speed.
> 
> Jan Høydahl
> 
>> 18. nov. 2019 kl. 06:26 skrev David Smiley :
>> 
>> 
>> This particular committer's meeting has a particular subject/theme.  So as 
>> Erick indicated, while all committers are invited, I think if you're not 
>> interested in the subject then I'm sure you can find a better use of your 
>> time.  The "Solr Implementation Proposal" could fit in I suppose, but not 
>> Gradle (sorry Erick).
>> 
>> Lets have another committer meeting in the near future too to discuss 
>> whatever Gradle and whatever.  I look forward to having more opportunities 
>> to collaborate with more direct synchronous conversation.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> 
>> On Sun, Nov 17, 2019 at 8:29 PM Ishan Chattopadhyaya 
>>  wrote:
>> Jan, I think that is something that merits its own mail thread or jira for 
>> broader community participation.
>> 
>> On Mon, 18 Nov, 2019, 5:19 AM Jan Høydahl,  wrote:
>> I added this bullet point under "Community":
>> 
>>  • Should we adopt a formal decision process for proposing major 
>> changes/APIs to Solr, aka "Solr Implementation Proposal (SIP)"?
>>  • See proposal from Jörn Franke in dev@ referring to KIP and 
>> FLIP
>> 
>> Example: With SIP we would probably not have ended up with three overlapping 
>> facet/stats implementations without a migration plan :)
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>>> 17. nov. 2019 kl. 15:13 skrev David Smiley :
>>> 
>>> The meeting will be held on Wednesday at 11am PST (2pm EST).  I'll send a 
>>> calendar invite tomorrow to those that used the Doodle poll.
>>> The agenda is here:  
>>> https://cwiki.apache.org/confluence/display/SOLR/2019-11+Meeting+on+SolrCloud+and+project+health
>>>Edit it if you wish.  If you can't (e.g. you are not a committer), then 
>>> maybe reply here to offer a suggestion.
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>> 
>>> 
>>> On Wed, Nov 13, 2019 at 1:56 PM David Smiley  
>>> wrote:
>>> 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 virtual committer meetings that are open-ended to discuss all manner 
>>> of things on our minds.
>>> 
>>> Why?  (A) I felt the committer meeting at Activate this year was 
>>> fantastically productive (B) I love opportunities to see/hear from my 
>>> awesome virtual colleagues (C) Mark raised issues of grave concern to our 
>>> community
>>> 
>>> When exactly is this?:  I'm using a "Doodle poll" to determine an optimal 
>>> time slot.  For the link to the poll, go to the ASF Slack, #solr-dev 
>>> channel, and you will see it.  You could also email me directly for it.
>>> 
>>> For this virtual committer meeting and future ones:
>>> * This is in the spirit of committer meetings co-located with conferences.  
>>> I recall that ASF policy says that no "decisions" can be made in such a 
>>> venue.  We make decisions on this dev list and indirectly via JIRA out in 
>>> the open and with the opportunity for anyone to comment.
>>> * Who:  Committer-only or by invitation
>>> * Video chat with option of audio dial-in.  This time I will use Google 
>>> Hangout.
>>> * Recorded for those invited only.  I'll dispose of the recording a week 
>>> after.  The intention is for those who cannot be there due to a scheduling 
>>> conflict to see/hear what was said.  I have the ability to do this 
>>> recording via Salesforce's G-Suite subscription.
>>> * Published notes:  I (or someone) will take written meeting notes that are 
>>> ultimately published for anyone to see (not restricted to those invited).  
>>> They will be transmitted to the dev list.
>>> 
>>> Thanks everyone.  I hope we do more of these!  And I hope non-committers 
>>> don't feel slighted; the published notes is a great time to make your voice 
>>> heard here!  I'm open to suggestions.
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>> 


-
To 

Re: Propose Solr committer meeting next week

[David Smiley]

Google Hangout.  (see my first email of this thread)

I'll create/send the invite shortly.  It'll be for 1.5 hours, though I
understand not everyone can attend for that long.

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


On Mon, Nov 18, 2019 at 11:05 AM Mike Drob  wrote:

> What's the medium for this? Is somebody going to make a
> webex/zoom/meet/whatever link? I'd like to make sure I have the right tools
> installed and will do my best to join from airport wifi.
>
> On Mon, Nov 18, 2019 at 2:49 AM Jan Høydahl  wrote:
>
>> I view Jörn’s SIP proposal as a way for tighter gate keeping of future
>> major changes, helping maintain hard fought stability and speed.
>>
>> Jan Høydahl
>>
>> 18. nov. 2019 kl. 06:26 skrev David Smiley :
>>
>> 
>> This particular committer's meeting has a particular subject/theme.  So
>> as Erick indicated, while all committers are invited, I think if you're not
>> interested in the subject then I'm sure you can find a better use of your
>> time.  The "Solr Implementation Proposal" could fit in I suppose, but not
>> Gradle (sorry Erick).
>>
>> Lets have another committer meeting in the near future too to discuss
>> whatever Gradle and whatever.  I look forward to having more opportunities
>> to collaborate with more direct synchronous conversation.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, Nov 17, 2019 at 8:29 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Jan, I think that is something that merits its own mail thread or jira
>>> for broader community participation.
>>>
>>> On Mon, 18 Nov, 2019, 5:19 AM Jan Høydahl, 
>>> wrote:
>>>
 I added this bullet point under "Community":


- Should we adopt a formal decision process for proposing major
changes/APIs to Solr, aka "Solr Implementation Proposal (SIP)"?
   - See proposal from Jörn Franke in dev@
   
 
  referring
   to KIP
   
 
and FLIP
   
 


 Example: With SIP we would probably not have ended up with three
 overlapping facet/stats implementations without a migration plan :)

 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com

 17. nov. 2019 kl. 15:13 skrev David Smiley :

 The meeting will be held on Wednesday at 11am PST (2pm EST).  I'll send
 a calendar invite tomorrow to those that used the Doodle poll.
 The agenda is here:
 https://cwiki.apache.org/confluence/display/SOLR/2019-11+Meeting+on+SolrCloud+and+project+health
   Edit it if you wish.  If you can't (e.g. you are not a committer), then
 maybe reply here to offer a suggestion.

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


 On Wed, Nov 13, 2019 at 1:56 PM David Smiley 
 wrote:

> 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 virtual committer meetings that are open-ended to discuss all 
> manner
> of things on our minds.
>
> Why?  (A) I felt the committer meeting at Activate this year was
> fantastically productive (B) I love opportunities to see/hear from my
> awesome virtual colleagues (C) Mark raised issues of grave concern to our
> community
>
> When exactly is this?:  I'm using a "Doodle poll" to determine an
> optimal time slot.  For the link to the poll, go to the ASF Slack,
> #solr-dev channel, and you will see it.  You could also email me directly
> for it.
>
> For this virtual committer meeting and future ones:
> * This is in the spirit of committer meetings co-located with
> conferences.  I recall that ASF policy says that no "decisions" can be 
> made
> in such a venue.  We make decisions on this dev list and indirectly via
> JIRA out in the open and with the opportunity for anyone to comment.
> * Who:  Committer-only or by invitation
> * Video chat with option of audio dial-in.  This time I will use
> Google Hangout.
> * Recorded for those invited only.  I'll dispose of the recording a
> week after.  The intention is for those who cannot be there due to a
> scheduling conflict to see/hear what was said.  I have the ability to do
> this recording via Salesforce's G-Suite subscription.
> 

BadApple

[Erick Erickson]

Short form:

Holding reasonably steady, except:

PackageManagerCLITest.testPackeageManager is failing over 50% of the time.

MoverReplicaHDFSTest.test failing over 40% of the time.

TestFstDirectAddressing.testDeDupeTails is failing 18% of the time.

Full output attached:


There were 154 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd
All tests that failed 4 weeks running will be BadApple'd unless there are 
objections

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   3.3  917 45  BasicAuthIntegrationTest.testBasicAuth
 0123   0.5  943  7  
DimensionalRoutedAliasUpdateProcessorTest.testCatTime
 0123   2.7  943 18  
DimensionalRoutedAliasUpdateProcessorTest.testTimeCat
 0123   8.3  961 91  
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
 0123  43.8  202 85  MoveReplicaHDFSTest.test
 0123   0.5  903  5  
ReindexCollectionTest.testSameTargetReindexing
 0123   4.8  104  5  ShardSplitTest.testSplitWithChaosMonkey
 0123   0.5  918  9  SystemCollectionCompatTest.testBackCompat
 0123   4.8  941 52  
TestCloudSearcherWarming.testRepFactor1LeaderStartup
 0123   2.7  946 77  
TestModelManagerPersistence.testFilePersistence
 0123   2.2  940 70  
TestModelManagerPersistence.testWrapperModelPersistence
 0123   1.6  921 19  
TestSkipOverseerOperations.testSkipLeaderOperations
 0123   0.6  905 11  TestStressLiveNodes.testStress
 0123   1.1  651  9  TestTlogReplica.testKillTlogReplica
 0123   4.2  112 11  
TestXYMultiPolygonShapeQueries.testRandomBig
 Will BadApple all tests above this line except ones listed at the 
top**

DO NOT ENABLE LIST:
MoveReplicaHDFSTest.testFailedMove
MoveReplicaHDFSTest.testNormalFailedMove
TestControlledRealTimeReopenThread.testCRTReopen
TestICUNormalizer2CharFilter.testRandomStrings
TestICUTokenizerCJK
TestImpersonationWithHadoopAuth.testForwarding
TestLTRReRankingPipeline.testDifferentTopN
TestRandomChains


DO NOT ANNOTATE LIST
CdcrBidirectionalTest.testBiDir
IndexSizeTriggerTest.testMergeIntegration
IndexSizeTriggerTest.testMixedBounds
IndexSizeTriggerTest.testSplitIntegration
IndexSizeTriggerTest.testTrigger
InfixSuggestersTest.testShutdownDuringBuild
ShardSplitTest.test
ShardSplitTest.testSplitMixedReplicaTypes
ShardSplitTest.testSplitWithChaosMonkey
TestLatLonShapeQueries.testRandomBig
TestRandomChains.testRandomChainsWithLargeStrings
TestTriggerIntegration.testSearchRate

Processing file (History bit 3): HOSS-2019-11-18.csv
Processing file (History bit 2): HOSS-2019-11-11.csv
Processing file (History bit 1): HOSS-2019-11-04.csv
Processing file (History bit 0): HOSS-2019-10-28.csv


Number of AwaitsFix: 38 Number of BadApples: 10


Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0  had  56 failures
Week: 1  had  66 failures
Week: 2  had  83 failures
Week: 3  had  56 failures


**Annotated tests that didn't fail in the last 4 weeks.

  **Tests removed from the next two lists because they were specified in 
'doNotEnable' in the properties file
 no tests removed

  **Annotations will be removed from the following tests because they haven't 
failed in the last 4 rollups.

  **Methods: 3
   FullSolrCloudDistribCmdsTest.test
   SolrZkClientTest.testSimpleUpdateACLs
   TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader


Failures in Hoss' reports for the last 4 rollups.

There were 154 unannotated tests that failed in Hoss' rollups. Ordered by the 
date I downloaded the rollup file, newest->oldest. See above for the dates the 
files were collected 
These tests were NOT BadApple'd or AwaitsFix'd
All tests that failed 4 weeks running will be BadApple'd unless there are 
objections

Failures in the last 4 reports..
   Report   Pct runsfails   test
 0123   3.3  917 45  BasicAuthIntegrationTest.testBasicAuth
 0123   0.5  943  7  
DimensionalRoutedAliasUpdateProcessorTest.testCatTime
 0123   2.7  943 18  
DimensionalRoutedAliasUpdateProcessorTest.testTimeCat
 0123   8.3  961 91  
LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
 0123  43.8  202 85  MoveReplicaHDFSTest.test
 0123   0.5  903  5  
ReindexCollectionTest.testSameTargetReindexing
 0123   4.8  104  5  ShardSplitTest.testSplitWithChaosMonkey
 0123   0.5  918  9  SystemCollectionCompatTest.testBackCompat
 0123   4.8  941 52  

Re: Propose Solr committer meeting next week

[Mike Drob]

What's the medium for this? Is somebody going to make a
webex/zoom/meet/whatever link? I'd like to make sure I have the right tools
installed and will do my best to join from airport wifi.

On Mon, Nov 18, 2019 at 2:49 AM Jan Høydahl  wrote:

> I view Jörn’s SIP proposal as a way for tighter gate keeping of future
> major changes, helping maintain hard fought stability and speed.
>
> Jan Høydahl
>
> 18. nov. 2019 kl. 06:26 skrev David Smiley :
>
> 
> This particular committer's meeting has a particular subject/theme.  So as
> Erick indicated, while all committers are invited, I think if you're not
> interested in the subject then I'm sure you can find a better use of your
> time.  The "Solr Implementation Proposal" could fit in I suppose, but not
> Gradle (sorry Erick).
>
> Lets have another committer meeting in the near future too to discuss
> whatever Gradle and whatever.  I look forward to having more opportunities
> to collaborate with more direct synchronous conversation.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Nov 17, 2019 at 8:29 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Jan, I think that is something that merits its own mail thread or jira
>> for broader community participation.
>>
>> On Mon, 18 Nov, 2019, 5:19 AM Jan Høydahl,  wrote:
>>
>>> I added this bullet point under "Community":
>>>
>>>
>>>- Should we adopt a formal decision process for proposing major
>>>changes/APIs to Solr, aka "Solr Implementation Proposal (SIP)"?
>>>   - See proposal from Jörn Franke in dev@
>>>   
>>> 
>>>  referring
>>>   to KIP
>>>   
>>> 
>>>and FLIP
>>>   
>>> 
>>>
>>>
>>> Example: With SIP we would probably not have ended up with three
>>> overlapping facet/stats implementations without a migration plan :)
>>>
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>>
>>> 17. nov. 2019 kl. 15:13 skrev David Smiley :
>>>
>>> The meeting will be held on Wednesday at 11am PST (2pm EST).  I'll send
>>> a calendar invite tomorrow to those that used the Doodle poll.
>>> The agenda is here:
>>> https://cwiki.apache.org/confluence/display/SOLR/2019-11+Meeting+on+SolrCloud+and+project+health
>>>   Edit it if you wish.  If you can't (e.g. you are not a committer), then
>>> maybe reply here to offer a suggestion.
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Wed, Nov 13, 2019 at 1:56 PM David Smiley 
>>> wrote:
>>>
 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 virtual committer meetings that are open-ended to discuss all manner
 of things on our minds.

 Why?  (A) I felt the committer meeting at Activate this year was
 fantastically productive (B) I love opportunities to see/hear from my
 awesome virtual colleagues (C) Mark raised issues of grave concern to our
 community

 When exactly is this?:  I'm using a "Doodle poll" to determine an
 optimal time slot.  For the link to the poll, go to the ASF Slack,
 #solr-dev channel, and you will see it.  You could also email me directly
 for it.

 For this virtual committer meeting and future ones:
 * This is in the spirit of committer meetings co-located with
 conferences.  I recall that ASF policy says that no "decisions" can be made
 in such a venue.  We make decisions on this dev list and indirectly via
 JIRA out in the open and with the opportunity for anyone to comment.
 * Who:  Committer-only or by invitation
 * Video chat with option of audio dial-in.  This time I will use Google
 Hangout.
 * Recorded for those invited only.  I'll dispose of the recording a
 week after.  The intention is for those who cannot be there due to a
 scheduling conflict to see/hear what was said.  I have the ability to do
 this recording via Salesforce's G-Suite subscription.
 * Published notes:  I (or someone) will take written meeting notes that
 are ultimately published for anyone to see (not restricted to those
 invited).  They will be transmitted to the dev list.

 Thanks everyone.  I hope we do more of these!  And I hope
 non-committers don't feel slighted; the published notes is a great time to
 make your voice heard here!  I'm open to suggestions.

 ~ David Smiley
 Apache 

Re: Welcome Houston Putman as Lucene/Solr committer

[Martin Gainty]

welcome Houston!
martin-

From: Michael McCandless 
Sent: Sunday, November 17, 2019 10:32 AM
To: dev@lucene.apache.org 
Cc: Houston Putman 
Subject: Re: Welcome Houston Putman as Lucene/Solr committer

Welcome Houston!

Mike

On Thu, Nov 14, 2019 at 3:58 AM Anshum Gupta 
mailto:ans...@anshumgupta.net>> wrote:
Hi all,

Please join me in welcoming Houston Putman as the latest Lucene/Solr committer!

Houston has been involved with the community since 2013, when he first 
contributed the Analytics contrib module. Since then he has been involved with 
the community, participated in conferences and spoken about his work with 
Lucene/Solr. In the recent past, he has been involved with getting Solr to 
scale on Kubernetes.

Looking forward to your commits to the Apache Lucene/Solr project :)

Congratulations and welcome, Houston! It's a tradition to introduce yourself 
with a brief bio.

--
Anshum Gupta
--
Mike McCandless

http://blog.mikemccandless.com

Re: Do we want to pursue an LTS designation?

[Jan Høydahl]

I just removed LTS wording from the Solr download page.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 18. nov. 2019 kl. 09:22 skrev Bram Van Dam :
> 
> On 15/11/2019 23:07, Erick Erickson wrote:
>> Andrzej Bailecki and I worked on something similar, it might be good to 
>> compare notes. I gave a talk last Activate that might be useful for you to 
>> look at for ideas.
>> https://www.youtube.com/watch?v=eaQBH_H3d3g
> 
> Thanks, that sounds super useful! I'll look into it.
> 
> - Bram
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Propose Solr committer meeting next week

[Jan Høydahl]

I view Jörn’s SIP proposal as a way for tighter gate keeping of future major 
changes, helping maintain hard fought stability and speed.

Jan Høydahl

> 18. nov. 2019 kl. 06:26 skrev David Smiley :
> 
> 
> This particular committer's meeting has a particular subject/theme.  So as 
> Erick indicated, while all committers are invited, I think if you're not 
> interested in the subject then I'm sure you can find a better use of your 
> time.  The "Solr Implementation Proposal" could fit in I suppose, but not 
> Gradle (sorry Erick).
> 
> Lets have another committer meeting in the near future too to discuss 
> whatever Gradle and whatever.  I look forward to having more opportunities to 
> collaborate with more direct synchronous conversation.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
>> On Sun, Nov 17, 2019 at 8:29 PM Ishan Chattopadhyaya 
>>  wrote:
>> Jan, I think that is something that merits its own mail thread or jira for 
>> broader community participation.
>> 
>>> On Mon, 18 Nov, 2019, 5:19 AM Jan Høydahl,  wrote:
>>> I added this bullet point under "Community":
>>> 
>>> Should we adopt a formal decision process for proposing major changes/APIs 
>>> to Solr, aka "Solr Implementation Proposal (SIP)"?
>>> See proposal from Jörn Franke in dev@ referring to KIP and FLIP
>>> 
>>> Example: With SIP we would probably not have ended up with three 
>>> overlapping facet/stats implementations without a migration plan :)
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com
>>> 
 17. nov. 2019 kl. 15:13 skrev David Smiley :
 
 The meeting will be held on Wednesday at 11am PST (2pm EST).  I'll send a 
 calendar invite tomorrow to those that used the Doodle poll.
 The agenda is here:  
 https://cwiki.apache.org/confluence/display/SOLR/2019-11+Meeting+on+SolrCloud+and+project+health
Edit it if you wish.  If you can't (e.g. you are not a committer), then 
 maybe reply here to offer a suggestion.
 
 ~ David Smiley
 Apache Lucene/Solr Search Developer
 http://www.linkedin.com/in/davidwsmiley
 
 
> On Wed, Nov 13, 2019 at 1:56 PM David Smiley  
> wrote:
> 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 virtual committer meetings that are open-ended to discuss all 
> manner of things on our minds.
> 
> Why?  (A) I felt the committer meeting at Activate this year was 
> fantastically productive (B) I love opportunities to see/hear from my 
> awesome virtual colleagues (C) Mark raised issues of grave concern to our 
> community
> 
> When exactly is this?:  I'm using a "Doodle poll" to determine an optimal 
> time slot.  For the link to the poll, go to the ASF Slack, #solr-dev 
> channel, and you will see it.  You could also email me directly for it.
> 
> For this virtual committer meeting and future ones:
> * This is in the spirit of committer meetings co-located with 
> conferences.  I recall that ASF policy says that no "decisions" can be 
> made in such a venue.  We make decisions on this dev list and indirectly 
> via JIRA out in the open and with the opportunity for anyone to comment.
> * Who:  Committer-only or by invitation
> * Video chat with option of audio dial-in.  This time I will use Google 
> Hangout.
> * Recorded for those invited only.  I'll dispose of the recording a week 
> after.  The intention is for those who cannot be there due to a 
> scheduling conflict to see/hear what was said.  I have the ability to do 
> this recording via Salesforce's G-Suite subscription.
> * Published notes:  I (or someone) will take written meeting notes that 
> are ultimately published for anyone to see (not restricted to those 
> invited).  They will be transmitted to the dev list.
> 
> Thanks everyone.  I hope we do more of these!  And I hope non-committers 
> don't feel slighted; the published notes is a great time to make your 
> voice heard here!  I'm open to suggestions.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>>> 

Re: Do we want to pursue an LTS designation?

[Bram Van Dam]

On 15/11/2019 23:07, Erick Erickson wrote:
> Andrzej Bailecki and I worked on something similar, it might be good to 
> compare notes. I gave a talk last Activate that might be useful for you to 
> look at for ideas.
> https://www.youtube.com/watch?v=eaQBH_H3d3g

Thanks, that sounds super useful! I'll look into it.

 - Bram

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

RE: Lucene index upgrade from 4.6 to 8 facing issue

[Jyothsna Bavisetti]

Hi All,

Could please share some points when to go with longBitset vs FixedBitSet.

I read below Points:

BitSet of fixed length (numBits), backed by accessible (getBits()) long[], 
accessed with a long index. Use it only if you intend to store more than 2.1B 
bits, otherwise you should use FixedBitSet.
NOTE: This API is for internal purposes only and might change in incompatible 
ways in the next release.


Thanks,
Jyothsna
-Original Message-
From: Jyothsna Bavisetti
Sent: Wednesday, October 2, 2019 2:49 AM
To: dev@lucene.apache.org
Subject: RE: Lucene index upgrade from 4.6 to 8 facing issue

Hi Shawn,

Any doc or links for re indexing process. We are using Lucene core 8.0.0.


Thanks,
Jyothsna

-Original Message-
From: Jyothsna Bavisetti
Sent: Thursday, September 26, 2019 11:51 PM
To: dev@lucene.apache.org
Subject: RE: Lucene index upgrade from 4.6 to 8 facing issue

Hi Shawn,

Re-indexing is costly transaction in my use case as it takes more than three 
days. Please let me know if any work around?

Thanks,
Jyothsna
-Original Message-
From: Shawn Heisey 
Sent: Thursday, September 26, 2019 11:35 PM
To: dev@lucene.apache.org
Subject: Re: Lucene index upgrade from 4.6 to 8 facing issue

On 9/26/2019 11:41 AM, Jyothsna Bavisetti wrote:
> I am trying to upgrade Lucene index from 4.6 to 8.0.0. When I'm trying 
> to upgrade tool using:
> 
> java -cp lucene-core.jar:lucene-backward-codecs.jar \
> 
> org.apache.lucene.index.IndexUpgrader-delete-prior-commits  \



> Please let me know any option other than reindexing.

If you're upgrading more than one major version, you must reindex. 
Multiple major version upgrades have always been discouraged and never 
guaranteed to work, but now such upgrades are explicitly denied.

When you used the IndexUpgrader from Lucene 6, the Lucene version was written 
into the index.  The recorded version was preserved by the upgrader for version 
7.  When the index was subsequently read by version 8, it complained because 
the original index was not written by version 7 or later.

Thanks,
Shawn

-
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