[ 
https://issues.apache.org/jira/browse/SOLR-12028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384298#comment-16384298
 ] 

Erick Erickson commented on SOLR-12028:
---------------------------------------

Then change it to point back to 7736, I really don't care. My initial changes 
were essentially straw-man. I'm perfectly happy to have that late-night 
judgement call reversed if you feel strongly about it.

Here's the tests that have failed since 12028 (not even including the Lucene 
"can't delete file" list), we have far more productive things to do than argue 
over that one.

junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation
org.apache.lucene.analysis.core.TestRandomChains
org.apache.lucene.analysis.core.TestRandomChains.testRandomChains
org.apache.solr.client.solrj.request.TestV2Request.testCloudSolrClient
org.apache.solr.client.solrj.request.TestV2Request.testHttpSolrClient
org.apache.solr.cloud.AliasIntegrationTest.testMetadata
org.apache.solr.cloud.AliasIntegrationTest.testModifyMetadataCAR
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI
org.apache.solr.cloud.LegacyCloudClusterPropTest.testCreateCollectionSwitchLegacyCloud
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv
org.apache.solr.cloud.ZkShardTermsTest.testParticipationOfReplicas
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest 
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionsAPI
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitAfterFailedSplit
org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitWithChaosMonkey
org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeLostTriggerRestoreState
org.apache.solr.core.TestDynamicLoading.testDynamicLoading


> BadApple and AwaitsFix annotations usage
> ----------------------------------------
>
>                 Key: SOLR-12028
>                 URL: https://issues.apache.org/jira/browse/SOLR-12028
>             Project: Solr
>          Issue Type: Task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Tests
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Major
>         Attachments: SOLR-12016-buildsystem.patch, 
> SOLR-12028-sysprops-reproduce.patch, SOLR-12028.patch, SOLR-12028.patch
>
>
> There's a long discussion of this topic at SOLR-12016. Here's a summary:
> - BadApple annotations are used for tests that intermittently fail, say < 30% 
> of the time. Tests that fail more often shold be moved to AwaitsFix. This is, 
> of course, a judgement call
> - AwaitsFix annotations are used for tests that, for some reason, the problem 
> can't be fixed immediately. Likely reasons are third-party dependencies, 
> extreme difficulty tracking down, dependency on another JIRA etc.
> Jenkins jobs will typically run with BadApple disabled to cut down on noise. 
> Periodically Jenkins jobs will be run with BadApples enabled so BadApple 
> tests won't be lost and reports can be generated. Tests that run with 
> BadApples disabled that fail require _immediate_ attention.
> The default for developers is that BadApple is enabled.
> If you are working on one of these tests and cannot get the test to fail 
> locally, it is perfectly acceptable to comment the annotation out. You should 
> let the dev list know that this is deliberate.
> This JIRA is a placeholder for BadApple tests to point to between the times 
> they're identified as BadApple and they're either fixed or changed to 
> AwaitsFix or assigned their own JIRA.
> I've assigned this to myself to track so I don't lose track of it. No one 
> person will fix all of these issues, this will be an ongoing technical debt 
> cleanup effort.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Reply via email to