The “QA Contact” field on BMO will soon go back to containing the email address of a real QA contact; new component watching should instead be done using the new “Component Watching” facility. Watching a component by watching a specific specially-named user will still work, but is deprecated. However, you can still CC the specially-named user on bugs in order to send mail to anyone watching the associated component.

This change should have no effect on which bugmail people receive.

Background

For quite some time bugzilla.mozilla.org has (ab)used the “QA Contact” field, in combination with the “watch user” facility, to allow users to receive emails for all bug changes that happen in a given component. While this has worked well, it has left the QA team fieldless.

In early 2011 an extension to Bugzilla was developed and deployed which allows your to watch components directly, rather than watching the dummy users which were set as the QA contacts. This has opened the way for us to finally return the “QA Contact” field back to the QA team.

Why are you doing this?

Currently there is no clear way for someone to own the verification part of a bug, so reclaiming the QA Contact field would significantly help the QA process.

The component watching facility has a number of advantages over watching users: it is easier to configure, and you can watch entire products rather than trying to keep your preferences current with a list of dummy QA contact email addresses, one for each component.

What will not change?

If you are currently watching dummy QA users, you will continue to receive the same notifications without the need for you to take any action. Your prefs will continue to show you as watching the dummy users; however we suggest you migrate yourself to using component watching.

What will change?

All bugs that have a component-watching QA user will be updated; the QA contact field will be cleared out. This change will not trigger any emails.

The ‘reason’ for the emails you receive will change from “watching the QA contact” to “watching the component” in the footer, and from “QAcontact” to “Component-Watcher” in the X-Bugzilla-Reason header. This may require updates to any email filtering you have.

What will not change yet?

User preferences. At some point later, we will be automatically migrating the preferences across so that people who are watching the specially-named users will instead show up as watching the associated components. The two actions are exactly equivalent, so this should not lead to any change in the bugmail being received. However, it will mean the Bugzilla preferences UI more correctly reflects the user’s intent and the actual outcome.

Where do I report problems?

Problems should be filed in bugzilla.mozilla.org / Extensions: Component Watching.

it uses the possible duplicates function that you see when filing a new bug to display results as you update the search term. while it’s much quicker than other searching mechanisms, it’s also very limited – only the bug’s summaries are searched.

one item of note is it uses the related products facility from the guided bug entry form to automatically search related products; eg. if you select firefox as the product, the core and toolkit products will also be searched.

you can find it at bzr.mozilla.org/bmo – we’re currently running the 4.0 branch.

timeless has pointed mxr-test to the bmo source: mxr-test.mozilla.org/bugzillamozilla-bzr

a feature of the voting system within bugzilla is the ability to automatically bump a bug from UNCONFIRMED to NEW based on the number of votes for the bug. This feature is enabled on bugzilla.mozilla.org, with the per-product setting ranging between 1 and 10,000 votes.

chris lawson recently pointed out that voting should not be linked with triage.  i think he’s right.

echoing chris’s comment on bug 702704 i think disabling vote-to-confirm across all products on bugzilla.mozilla.org will clarify the triage process. owners of products who want to continue to use this feature will be required to ask to be excluded from this mass change, or request the feature be re-enabled.

any objections/thoughts?

view/comment on the thread.

“simple search” no longer searches comments by default.

previously simple search performed a full-text search in the summary field and all comments, resulting in painfully slow queries.  you now have to opt-in to searching comments.

this change will not impact any existing bookmarks, which will continue to search comments.

“google search” added.

for some time we’ve been providing a sitemap to google to allow them to index public bugs on BMO; we’ve added a quick mechanism to search BMO via google.

Using the Tweaks implementation as a guide, I have implemented an Inline History Bugzilla extension:

This extension has just been deployed to BMO and is currently disabled by default.  To enable you have to be logged in, then go your User Preferences, and set When viewing a bug, show all bug activity to on.

Once we’re happy with it it will be enabled by default for all logged-in users.  [Edit: Now enabled by default]

The latest version of Bugzilla Tweaks (v1.11) will detect when this Bugzilla extension is active, and will disable its inline history implementation.  The option to disable the extension will always be available should someone perfer Bugzilla Tweaks’ formatting over the extension’s.

the goal is to continue to treat the add-on as a platform for experimental features, with an eye to bringing valuable features upstream to land on bmo or in bugzilla itself.

work on implementing inline history on bmo as a bugzilla extension is nearly complete (bug 668506), which should bring tweak’s most noticeable feature to all logged-in bmo users, and also allow other bugzilla instances to deploy the extension onto their site.

some of the other tweaks have already been implemented in bugzilla itself (adding quicksearch terms to header/footer fields, after POSTing redirect to the show_bug page, making the comment box bigger), some will have to stay as a firefox add-on (copy commit comment), and the remaining features will need to be triaged.

the code for tweaks will remain on bitbucket, however issue tracking will move to bmo.