Platform/GFX/TriageSchedule

Overview

This document outlines the triage process for Graphics. It also includes some instructions for WebRender triage.

Process

• This is a rotating duty. Each individual will be in charge of a week worth of new bugs, assigned to nobody, starting Saturday, ending Friday. You would then have one extra week to act on them, so that a bug is at most 14 days old by the time somebody looks at it.
• There is a weekly Firefox management triage review on Thursdays. Ideally you will triage what you are able from your queue by end-of-day Wednesday to avoid us making the leaderboard. See the Pending Untriaged section.
• At this pace, everybody will get this duty once per quarter. The schedule is in the shared calendar (see above), and it should be self-managing - if you want to trade your week with somebody else, you should be able to just move the item around.
• The goal is to make sure we don’t miss something important, completely or until “late”, and also notice any trends we may have with crashes or intermittent failures, or in any particular areas of the code. The idea is to categorize the bugs as they come in so that we know which ones need a jump on, which ones can wait a bit, maybe ask for some information that is missing, maybe CC the right people, etc.
• We will cover these components: Canvas: 2D, Canvas: WebGL, GFX: Color Management, Graphics, Graphics: Layers, Graphics: Text, Image Blocking, ImageLib, WebRender.
• Some guidelines:
  • A good guideline should be ~15 minutes per bug, which is probably about hour and a half a day for the two weeks, but lets see what we really need as we get going.
  • This isn’t about finding a cause, and it isn’t about the full prioritization.
  • This is about noticing things sooner.
  • This is about asking the bug author for info that may be missing or would help with the triage.
  • This is about asking for a regression range, or even getting one if you can reproduce the problem and you have time.
  • This is about CC-ing the people on the team (or elsewhere) you’re guessing could shed more light on the issue.
  • This is about doing an occasional needinfo, and should be reserved for what you deem is a high priority.
  • Some types of bugs would be handled outside of this triage process; for example, intermittent test errors can get the priority set with a quick check if it's something obvious, not really spending time to resolve the issue if it takes a larger effort.

Keywords

• Add the relevant keywords:
  • "crash" if it's a crash;
  • "hang" if it's a hang;
  • "perf" if it's a performance related issue;
  • "reproducible" if it's reproducible
  • "feature" if it's new code, doing something that wasn't done before; note that a "feature" can block a "crash", we want a wide definition;
  • "regression" - not quite sure about this, we may want to save it for really bad and immediate regressions only?

• Clean up the bug:
  • set the correct platform if it's obvious and we're reasonably certain (e.g., DirectX issue is going to be Windows);
  • if we know how to reproduce it, set the "Has STR" field; if there is a regression range, set that as well.
• Set the priority field (P1-P5 under importance) at the time that you consider triaged. This will remove it from your queue. Here are some guidelines about priorities in Bugzilla: https://mozilla.github.io/bug-handling/triage-bugzilla#how-do-you-triage
  • If you are not sure, set it to P3.
  • If you are going to fix it in this release, set it to P1. Note - this is not the same as thinking it should be fixed in this release. It's a scheduling note, not a priority setting.
  • If you are going to fix it in the next release, set it to P2. Are you sure though? Do you know you will have time?
  • If you don't think we will ever have the time to spend on this, can ship for years without fixing it, and will take a patch if a contributor produces it, set it to P5.

• Consider the Severity value (blocker, critical, major, etc. under Importance)
  • If it's already set to anything higher than normal, please CC Jessie.
  • If you think it should be set to higher than normal, please do so, then CC Jessie.

Schedule

The schedule is tracked in a shared calendar, ID mozilla.com_6059q0oha1t7ueamb52cs7vegk@group.calendar.google.com and in case of difference with that and the table below, the shared calendar wins.

See dashboard for the schedule and current counts.

Old Feedback on Process

• (Kats) Current method gives people exposure to other parts of the the code, but without sufficient context to properly triage bugs (no history of what landed recently, or if other similar bugs were reported in the past week). I would still prefer a component-watching approach
• (Kats) Intermittents are more challenging to deal with - if it's a low-volume initially and later increases in volume who is responsible for it?

WebRender Triage

As of March 2019, we are going to include the WebRender component in our regular triage process. This provides guidelines for how to do triage for WebRender.

For MVP

These instructions apply specifically to triage for our MVP. Here is what you need to know about triaging bugs for the MVP:

• What is our MVP?
  • WR Windows 10, Desktop, with NVIDIA graphics cards
• When is it shipping?
  • It will officially ship with 67 (May 14th)
  • We are going to conduct an experiment in release for 66 (after March 19th)

Triage buckets for the MVP

These are bugs that we think are reasonable to fix and do not introduce significant risk to ship with our MVP in 67

• P2 - 67: https://mzl.la/2Tl4Awv
• P3 - 67: https://mzl.la/2TrRcGU

If you come across a bug during your triage that you suspect could be valuable for the MVP, ping Jeff or Jessie and we can help make that call.

We also have a list for bugs we’d like to fix for 68:

• P2 - 68: https://mzl.la/2Uf6Ges

Non-MVP specific Bugs

We want to continue shipping WR on various platforms throughout the year. Let's try and follow similar prioritization guidelines as our regular triage:

• P1 - Must fix in order to release on specified platform (ie. intel, android, etc.)
• P2 - Fix for the next release for specified platform
• P3 - Backlog for specified platform platform
• P4 - Don’t use
• P5 - Won’t fix, but will accept patch

We also have tracking bugs set up for some of the platforms we want to target and other important categories we want to track (such as performance). Please also add the appropriate tracking bug as you are doing your triage:

• wr-intel
• wr-android
• wr-android-mvp
• wr-mac
• wr-linux
• wr-perf
• wr-snap