Bugzilla

Tracy had a meeting with QA on this, he can fill in the details on what steps we're taking within that team. Generally we spoke about:

1) While hulu was covered in Nightly and Beta, this bug was not identified. QA team is aware of this and is assessing how that happened, and what steps we can take to mitigate that in the future.

2) We identified a better process for bug filing. The original bug was filed by default as an S3, which was a mistake. In the future these bugs (based on the best judgement of the QA team) should
- not have a default severity assigned so that they fall into the team's regular triage process.
- potentially be marked as tracking:? if they seem serious, so that REOs pick them up and can follow up on them.

One other note I would add that I thought of after I spoke with Tracy - 
- require regression ranges vs. guessing where the regression occurred.

Tracy and I met after he had a meeting with QA on this, so he can fill in the details on what steps we're taking within that team. Generally we spoke about:

1) While hulu testing *was* covered in Nightly and Beta pre-release testing, this bug was not identified. QA team is aware of this and is assessing how that happened, and what steps we can take to mitigate that in the future.

2) We identified a better process for bug filing. The original bug was filed by default as an S3, which was a mistake. In the future these bugs (based on the best judgement of the QA team) should:

- not have a default severity assigned so that they fall into the team's regular triage process.
- potentially be marked as tracking:? if they seem serious, so that REOs pick them up and can follow up on them.

One other note I would add that I thought of after I spoke with Tracy - 
- require regression ranges vs. guessing what release the regression occurred in would have helped. The bug was misidentified as a long standing issues vs. a fresh regression, which threw engineering off on the severity.