BadApple report. It's worth reviewing the SuppressWarnings section even if you ignore the rest.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

BadApple report. It's worth reviewing the SuppressWarnings section even if you ignore the rest.

Erick Erickson
This week is a significant improvement. Short form:


Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0  had  68 failures
Week: 1  had  113 failures
Week: 2  had  103 failures
Week: 3  had  102 failures


********Failures in Hoss' reports for the last 4 rollups.

There were 273 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

Failures in the last 4 reports..
   Report   Pct     runs    fails           test
     0123   3.1     1601     41      BasicDistributedZkTest.test
     0123   1.7     1495     28      MultiThreadedOCPTest.test
     0123   1.0     1587     14      RollingRestartTest.test
     0123   3.1     1653     55      ScheduledTriggerIntegrationTest.testScheduledTrigger
     0123   1.3     1574     13      SystemCollectionCompatTest.testBackCompat
     0123   1.6     1571     14      TestPackages.testPluginLoading
     0123   0.3     1570      7      TestQueryingOnDownCollection.testQueryToDownCollectionShouldFailFast
********************************************

=====================SuppressWarnings======================

In the attached report there’s a new section counting SuppressWarnings. For the nonce, ignore it. Eventually, when all the warnings are fixed or suppressed, I will be advocating for _not_ introducing new warnings at least on Master. To encourage this, I want un-suppressed warnings to become compile-time errors.

That’ll tempt people to just add @SuppressWarnings, and I don’t think that’s a proper fix, so the BadApple report will flag files that have more @SuppressWarnings than they did last week and I’ll complain ;) There’ll be exceptions of course...

Yes, that flies counter to the zillion SuppressWarnings I’m putting in the code right now, but I’m not about to try to fix on the order of 5,000 warnings in our code all at once. that’s where the SuppressWarnings data is coming from in the attached report, I expect the counts to increase until we get clean compilations. Martin Fowler talks about rewriting working code for no good reason being a bad idea in “Refactoring”...

My goal currently is to get the compilations clean, stop getting worse, and then we can make things better. Along about 2040, all the code that currently has SuppressWarnings will have been rewritten and they’ll all be gone...

==================================
Full report:







---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

e-mail-2020-06-01.txt (28K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BadApple report. It's worth reviewing the SuppressWarnings section even if you ignore the rest.

Noble Paul നോബിള്‍  नोब्ळ्
Is there a way to see the failures and their logs?

On Tue, Jun 2, 2020 at 12:02 AM Erick Erickson <[hidden email]> wrote:

>
> This week is a significant improvement. Short form:
>
>
> Raw fail count by week totals, most recent week first (corresponds to bits):
> Week: 0  had  68 failures
> Week: 1  had  113 failures
> Week: 2  had  103 failures
> Week: 3  had  102 failures
>
>
> ********Failures in Hoss' reports for the last 4 rollups.
>
> There were 273 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
>
> Failures in the last 4 reports..
>    Report   Pct     runs    fails           test
>      0123   3.1     1601     41      BasicDistributedZkTest.test
>      0123   1.7     1495     28      MultiThreadedOCPTest.test
>      0123   1.0     1587     14      RollingRestartTest.test
>      0123   3.1     1653     55      ScheduledTriggerIntegrationTest.testScheduledTrigger
>      0123   1.3     1574     13      SystemCollectionCompatTest.testBackCompat
>      0123   1.6     1571     14      TestPackages.testPluginLoading
>      0123   0.3     1570      7      TestQueryingOnDownCollection.testQueryToDownCollectionShouldFailFast
> ********************************************
>
> =====================SuppressWarnings======================
>
> In the attached report there’s a new section counting SuppressWarnings. For the nonce, ignore it. Eventually, when all the warnings are fixed or suppressed, I will be advocating for _not_ introducing new warnings at least on Master. To encourage this, I want un-suppressed warnings to become compile-time errors.
>
> That’ll tempt people to just add @SuppressWarnings, and I don’t think that’s a proper fix, so the BadApple report will flag files that have more @SuppressWarnings than they did last week and I’ll complain ;) There’ll be exceptions of course...
>
> Yes, that flies counter to the zillion SuppressWarnings I’m putting in the code right now, but I’m not about to try to fix on the order of 5,000 warnings in our code all at once. that’s where the SuppressWarnings data is coming from in the attached report, I expect the counts to increase until we get clean compilations. Martin Fowler talks about rewriting working code for no good reason being a bad idea in “Refactoring”...
>
> My goal currently is to get the compilations clean, stop getting worse, and then we can make things better. Along about 2040, all the code that currently has SuppressWarnings will have been rewritten and they’ll all be gone...
>
> ==================================
> Full report:
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BadApple report. It's worth reviewing the SuppressWarnings section even if you ignore the rest.

Erick Erickson
If you go to Hoss’ rollups here: http://fucit.org/solr-jenkins-reports/

Click on "Failures rates for the last 24h/7days” then click on one of the tests you’ll get a popup with a link to the output. IDK how long the output is kept around though.

> On Jun 2, 2020, at 4:08 AM, Noble Paul <[hidden email]> wrote:
>
> Is there a way to see the failures and their logs?
>
> On Tue, Jun 2, 2020 at 12:02 AM Erick Erickson <[hidden email]> wrote:
>>
>> This week is a significant improvement. Short form:
>>
>>
>> Raw fail count by week totals, most recent week first (corresponds to bits):
>> Week: 0  had  68 failures
>> Week: 1  had  113 failures
>> Week: 2  had  103 failures
>> Week: 3  had  102 failures
>>
>>
>> ********Failures in Hoss' reports for the last 4 rollups.
>>
>> There were 273 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
>>
>> Failures in the last 4 reports..
>>   Report   Pct     runs    fails           test
>>     0123   3.1     1601     41      BasicDistributedZkTest.test
>>     0123   1.7     1495     28      MultiThreadedOCPTest.test
>>     0123   1.0     1587     14      RollingRestartTest.test
>>     0123   3.1     1653     55      ScheduledTriggerIntegrationTest.testScheduledTrigger
>>     0123   1.3     1574     13      SystemCollectionCompatTest.testBackCompat
>>     0123   1.6     1571     14      TestPackages.testPluginLoading
>>     0123   0.3     1570      7      TestQueryingOnDownCollection.testQueryToDownCollectionShouldFailFast
>> ********************************************
>>
>> =====================SuppressWarnings======================
>>
>> In the attached report there’s a new section counting SuppressWarnings. For the nonce, ignore it. Eventually, when all the warnings are fixed or suppressed, I will be advocating for _not_ introducing new warnings at least on Master. To encourage this, I want un-suppressed warnings to become compile-time errors.
>>
>> That’ll tempt people to just add @SuppressWarnings, and I don’t think that’s a proper fix, so the BadApple report will flag files that have more @SuppressWarnings than they did last week and I’ll complain ;) There’ll be exceptions of course...
>>
>> Yes, that flies counter to the zillion SuppressWarnings I’m putting in the code right now, but I’m not about to try to fix on the order of 5,000 warnings in our code all at once. that’s where the SuppressWarnings data is coming from in the attached report, I expect the counts to increase until we get clean compilations. Martin Fowler talks about rewriting working code for no good reason being a bad idea in “Refactoring”...
>>
>> My goal currently is to get the compilations clean, stop getting worse, and then we can make things better. Along about 2040, all the code that currently has SuppressWarnings will have been rewritten and they’ll all be gone...
>>
>> ==================================
>> Full report:
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]