[Findit] Use commit positions instead of build numbers for build-level exponential search |
|||
Issue descriptionExample here: https://findit-for-me.appspot.com/waterfall/flake?key=ag9zfmZpbmRpdC1mb3ItbWVysQELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCJ7Y2hyb21pdW0ubWVtb3J5L0xpbnV4IEFTYW4gTFNhbiBUZXN0cyAoMSkvMzgxODIvY2FzdF91bml0dGVzdHMvUlc1a01rVnVaRlJsYzNRdVUyaHZkbVZJYVdkb1JuSmhiV1ZTWVhSbFJHOTNibGxsY2xSb2NtOWhkQT09DAsSE01hc3RlckZsYWtlQW5hbHlzaXMYAQw It's strange that there's so many data points clustered at the front when we haven't found a 100% data point yet. Shouldn't we lookback until we find where the test is passing, then move forward to find where it failed? Ignore the error that it ended in -- we should improve how this works. Shouldn't we do an exponential search backward, then a binary search forward?
,
Aug 23 2017
,
Aug 23
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 by st...@chromium.org
, Aug 23 2017Summary: [Findit] Use commit positions instead build numbers for build-level exponential search (was: [Findit] Unusual distribution of data points when a test is flaky for a long time.)