Here is a quick explanation of how webrender does triage
Untriaged bugs can be found here.
Triaging a wr bug means setting a priority and marking it as blocking a given stage.
In doubt? Go with "stage-wr-trains P2", since it will probably get retriaged once we're further along.
- stage-wr-nightly: windows+nvidia, unacceptable to expose to nightly testers
- stage-wr-trains: windows+nvidia, unacceptable to expose to stable users
- stage-wr-next: all platforms/hardware
- stage-wr-backlog: nice to haves, theoretical cleanups and optimizations
note: wr-nightly is only P1s
- P1: very important - looking to find owners and land fixes asap -- could be blocking other WR development or solid use of the feature - Can't get into beta with these unresolved.
- P2: not blocking other developers or solid use of the feature, but it shows a regression or correctness problem that we can't ship with. We can ride into beta with these, but they need to be fixed before we ride-to-release
- P3: looks like a real problem, but not blocking in the way P1 or P2 is. Should be scrubbed to determine if it really needs to block shipping to release.
- P4-P5: don't use? (put in wr-backlog)
- wr-android: needed for that platform specifically
- wr-mac: needed for that platform specifically
- wr-perf: performance bugs
- webrender-site-issues: issues affecting real websites
- crashers:
- infrequent: stage-wr-next P3
- frequent: stage-wr-nightly P1
- unsure: stage-wr-trains P2
- imperfect rendering: stage-wr-next P1
- very bad rendering:
- common: stage-wr-nightly P1
- uncommon: stage-wr-trains P2/P1
- perf issues:
- severe: stage-wr-nightly P1
- common: stage-wr-trains P2
- rare: stage-wr-backlog
- intermittents: stage-wr-backlog (unless serious, then someone will prod us)