| Summary: | LayoutTest animations/animation-direction-normal.html fails on Chromium dbg bots | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Steve Block <steveblock> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | jchaffraix, pkasting, steveblock |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Steve Block
2011-11-16 03:49:44 PST
Committed r100429: <http://trac.webkit.org/changeset/100429> Above change simply sets failing test expectation 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. Landed http://trac.webkit.org/changeset/100458 (no idea how the commit message got messed up) (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. (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.) *** This bug has been marked as a duplicate of bug 66953 *** > 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.
> 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?
(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. |