Bugzilla guidelines

We use Bugzilla to track QE-reported bugs and QE verification of changes backported during a release window. We need to be active in managing BZs while we have an active release branch, but otherwise we can mostly ignore it unless QE opens a bug we need to look at.

Best practices

• If there is an issue in our repo that duplicates a BZ, a link to the BZ should be in the issue and a link to the issue should be in the BZ. GH issues for BZs are optional but can be helpful in managing assignment/labels/cross-linking during implementation.
• If a PR needs to be backported to a release branch, it needs to have an associated BZ.
• When opening a PR that will fix a BZ, put the prefix "Bug _____:" on it, where the blank is the BZ id number. This will cause a CI job to automatically cross-link the PR and the BZ. You can edit the PR title to add this if it already existed before the BZ, it should still work. If for some reason this doesn't work, manually put the link to the PR in the BZ and vice versa.
• The CI job should automatically move the BZ to POST and MODIFIED states when a PR is opened/merged, but we should always verify this by hand. Sometimes there is weirdness with base branches and target releases that break this automation.
• When discussing things in a BZ, if your comment includes any confidential info like server credentials, mark that comment as private with the checkbox above the field.
• If you are asking for information from someone else, use the needinfo fields at the bottom. The dropdowns there are finicky, you can always just type comma-separated email addresses in "needinfo other users".

Fields that matter when opening a BZ

• Product (Migration Toolkit for Virtualization)
• Component (usually User Experience or General, but if it's a backend bug you can put Controller or Operator)
• Version (the version the bug is present in)
• Severity (optional but saves us from setting it in the bug triage meeting if you are confident in the severity)
  • Note the distinction between Severity and Priority. Don't set the Priority without approval from QE or Paige/Fabien. It is usually set during the bug triage meetings.
• Target Release (the version we want to release the fix in, or pick some future version if we're not sure yet)
  • For bugs opened by QE, this shouldn't be changed without approval. Often adjusted during the bug triage meeting.
• Status (NEW or ASSIGNED at first. POST = PR exists, MODIFIED = PR merged. other states are handled by QE)
• Assignee (if you will be working on it put your email address, otherwise it will default to Fabien)
• needinfo (if you know you need a reply from someone, put their email here. can also add this on comments later)
• Internal Whiteboard (set it to "v2v")
• Summary (something hinting at expected behavior / how to verify the fix, usually)
• Description (don't have to include all the template stuff as long as it's clear how to reproduce the bug / verify the fix)
• Attachment (if there are relevant screenshots / yaml or something)

The rest can be left blank.

Handy search bookmarks

• All MTV bugs
• All MTV bugs with Component set to General, User Experience or Documentation
• MTV bugs that are NEW, ASSIGNED, ON_DEV or FAILED_QA and have Component set to General, User Experience or Documentation. Sorting this by target release is often useful.
• Here's a quick link to open a new bug on the Migration Toolkit for Virtualization product. This is also at the bottom of the search results pages.

You can use the "Change columns" button at the bottom to see more info on the search results pages.