72485 2011-11-16 03:49:44 -0800 LayoutTest animations/animation-direction-normal.html fails on Chromium dbg bots 2011-11-17 07:40:53 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 66953 P2 Normal --- 1 steveblock webkit-unassigned jchaffraix pkasting steveblock oldest_to_newest 503745 0 steveblock 2011-11-16 03:49:44 -0800 See http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=animations%2Fanimation-direction-normal.html Based on when the test started failing on Win (dbg) and Linux (dbg), it looks like this was caused by http://trac.webkit.org/changeset/100351/ 503751 1 steveblock 2011-11-16 03:57:34 -0800 Committed r100429: <http://trac.webkit.org/changeset/100429> 503752 2 steveblock 2011-11-16 03:59:05 -0800 Above change simply sets failing test expectation 503928 3 steveblock 2011-11-16 08:48:46 -0800 Looks like there's a similar failure in animations/play-state-paused.html on Mac 10.5 CG, though for some reason the flakiness dashboard isn't showing recent results - http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=animations%2Fplay-state-paused.html I'll add a TEXT expectation. 503948 4 steveblock 2011-11-16 09:06:59 -0800 Landed http://trac.webkit.org/changeset/100458 (no idea how the commit message got messed up) 504162 5 jchaffraix 2011-11-16 12:54:05 -0800 (In reply to comment #0) > See http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=animations%2Fanimation-direction-normal.html > > Based on when the test started failing on Win (dbg) and Linux (dbg), it looks like this was caused by http://trac.webkit.org/changeset/100351/ Your analysis is bogus: the change you are pointing to is a merge of a change that was committed 7 days ago in the trunk (see bug 71550). Based on the flakyness dashboard, the test was passing 4 days ago so unless I am missing something it cannot be the culprit. Now assigning bug to people is NOT a good practice. I would have come back to you and followed up on this bug based on just CC'ing and taking the bug / blame as appropriate. 504304 6 pkasting 2011-11-16 15:09:11 -0800 (In reply to comment #5) > Now assigning bug to people is NOT a good practice. I would have come back to you and followed up on this bug based on just CC'ing and taking the bug / blame as appropriate. Julien, I asked Steve to ensure that as he filed test bugs he assigned them to someone, even if it was the wrong someone, because otherwise no action would likely be taken -- see the hundreds of rotting test bugs we've filed in this DB for supporting evidence. It's always possible for an assignee to change the assignment, so please don't get upset at people if they assign you bugs wrongly -- and yes, assigning the bug is, indeed, good practice. BTW, the flakiness dashboard is pretty hosed right now so I would not trust any of its data too heavily when determining what's up. (I do agree that in this case r100351 seems like an unlikely candidate.) 504356 7 pkasting 2011-11-16 16:02:08 -0800 *** This bug has been marked as a duplicate of bug 66953 *** 504434 8 jchaffraix 2011-11-16 17:26:12 -0800 > It's always possible for an assignee to change the assignment, so please don't get upset at people if they assign you bugs wrongly -- and yes, assigning the bug is, indeed, good practice. I don't think I agree to your assumption that this gets more results. Most people if CC'ed on a bug and told that they are causing regressions would just jump on the spot and fix it. Assigning the bug to the rest will not make much of a difference because their usually have their share of tasks to do. It also prevents anyone from jumping in earlier and fixing it (ASSIGNED == I am working on it in WebKit). Lastly in WebKit, assigning people to random bugs - regardless of whether it is justified or not - is frowned upon, so please don't encourage it. 504666 9 steveblock 2011-11-17 02:02:43 -0800 > Lastly in WebKit, assigning people to random bugs - regardless of whether it is > justified or not - is frowned upon, so please don't encourage it. My understanding was that in general, bugs are only assigned once somebody starts working on them. However, pkasting's suggestion of setting an assignee for gardening bugs makes sense, and given that he has a lot more gardening experience than me, I followed it. Is there an official stance on this, so we're all on the same page next time? 504840 10 jchaffraix 2011-11-17 07:40:53 -0800 (In reply to comment #9) > > Lastly in WebKit, assigning people to random bugs - regardless of whether it is > > justified or not - is frowned upon, so please don't encourage it. > > However, pkasting's suggestion of setting an assignee for gardening bugs makes sense, and given that he has a lot more gardening experience than me, I followed it. No problem on my side, I would have found any such assignment in the same manner. I don't think I agree on such an opt-out policy (if you don't have enough bandwidth, just un-assign yourself) when the usual rule is an opt-in policy but then Peter likely has more data to back that up. > Is there an official stance on this, so we're all on the same page next time? The WebKit custom is mostly unwritten. My understanding is that it is done to avoid making assumptions on people's agendas. I am not sure making it 'official' would add much but it's definitely worth a try. I will follow up with Peter offline on the gardening side.