Closed Bug 1119742 Opened 5 years ago Closed 5 years ago
Timer Dispatcher into Vsync Source::Display
+++ This bug was initially created as a clone of Bug #1118841 +++ From bug 1092978, Part2: [Silk] Add RefreshTimerDispatcher into VsyncSource::Display. v4, r=kats (https://bugzilla.mozilla.org/attachment.cgi?id=8546520&action=edit), land this patch as this bug. Successful try - https://treeherder.mozilla.org/#/jobs?repo=try&revision=a58c2380a168
only change the bug number comment.
Attachment #8546531 - Attachment is obsolete: true
please land the attachment 8546533 [details] [diff] [review] to mozilla-central.
Needs rebasing, sorry.
please land the attachment 8546683 [details] [diff] [review] to mozilla-central.
sorry this does not apply cleanly: applying Bug-1119742---Add-RefreshTimerDispatcher-into-Vsyn.patch patching file gfx/thebes/VsyncSource.h Hunk #1 FAILED at 0 1 out of 1 hunks FAILED -- saving rejects to file gfx/thebes/VsyncSource.h.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh Bug-1119742---Add-RefreshTimerDispatcher-into-Vsyn.patch could you take a look ? Thanks!
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Jerry, please rebase and uplift to Gecko37.
Required as part of silk, bug 987532.
blocking-b2g: --- → 2.2?
No point in requesting blocking since you have to request uplift on the patch anyway; blocking bugs don't get a free uplift. The blocking status is just an extra unnecessary step.
blocking-b2g: 2.2? → ---
rebase for gecko37.
Comment on attachment 8548642 [details] [diff] [review] Add RefreshTimerDispatcher into VsyncSource::Display. for gecko37, r=kats [Approval Request Comment] Bug caused by (feature/regressing bug #): none User impact if declined: a part of silk, bug 987532. Testing completed: landed in m-c. m-c try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a58c2380a168 Risk to taking this patch (and alternatives if risky): small String or UUID changes made by this patch: none
Attachment #8548642 - Flags: approval-mozilla-b2g37?
(In reply to Kartikaya Gupta (email:email@example.com) from comment #12) > No point in requesting blocking since you have to request uplift on the > patch anyway; blocking bugs don't get a free uplift. The blocking status is > just an extra unnecessary step. Partially agree atleast for the next 6 weeks. The blocking/feature flag helps us track work that are committed(product, parter, QA ..etc) for the release. As an example, if we had a fallout from a non-blocking bug say 8 weeks down the line, then I would backout the bug/feature rather than having discussions on forward fixing etc. But if it was blocking then it indicates it is part of some sort of a must-have feature list for the 2.2 release and I'd rather have more discussions on how to forward fix/QA it. Obviously, it gets down to case-case discussion, but I just wanted to clear the assumption made here :)
Attachment #8548642 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Indeed. We should be safe requesting (and getting) blocking for any Silk related issues that truly block the Silk meta bug 987532. I'd say this is one of those.
Makes sense, thanks for the clarification. Restoring flag then.
blocking-b2g: --- → 2.2?
You need to log in before you can comment on or make changes to this bug.