Issue metadata
Sign in to add a comment
|
Wrong Findit result for 419384 |
||||||||||||||||||||||
Issue descriptionDetail is https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQAsSCVdmQ3VscHJpdCIxY2hyb21pdW0vZTFjYzAwYmU2YzE1MzI1YzAzYzc2OTliYjBmODk2ZDNlOWIzYmY0Mww FindIt fingers https://codereview.chromium.org/2345223002 as the culprit, but it was actually https://codereview.chromium.org/2345893004 . They are very similar, though, and I wouldn't blame FindIt.
,
Oct 17 2016
,
Oct 17 2016
> avi@, what results do you expect Findit to surface on Sheriff-o-Matic in this case? Honestly, given those two CLs, I completely don't blame Findit, and I didn't have a problem working out the real culprit even without it. But you wanted examples of Findit failing, so I sent this to you. I don't know if this is actionable; I wouldn't mind if you closed this if you couldn't easily improve things.
,
Oct 18 2016
,
Oct 18 2016
A quick glance at this one and something seems not right. There are 3 CLs in the regression range, the first of them was the culprit (call it r1), the middle a deps roll (call it r2), then the last the similar CL that Findit thinks was the culprit (call it r3). Because both r1 and r3 showed up as hints in Findit's heuristic analysis, the try job was guided to test r2 (expecting it to pass) and r3 (expecting it to fail), which is exactly what happened. However what I'm curious about is why r2 passed in the first place, since r1 would already have been in there causing problems. I don't have bandwidth to look into this any further for this week, but for now I think it's worth keeping open since it seems like something else might be wrong.
,
Apr 25 2017
The scenario is conflicting CLs landed around the same time. This is not actionable for Findit, so closed. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by st...@chromium.org
, Oct 17 2016Status: Assigned (was: Available)