Release Management

• Alex Keybl
• Firefox Desktop/Mobile/Metro Focus
  • RM Lukas Blakk (focus lead)
  • Incoming Candidate – apply here
  • Community Release Management – get involved!
• Firefox OS Focus
  • Sr. RM Preeti Raghunath (focus lead)
  • RM Bhavana Bajaj

Our Firefox OS release managers will typically be focused on a single converging release, while our desktop/mobile release managers will continue to track a release each. I’ll manage both groups and pinch hit as necessary. Our hope is that this model will enable release managers to better embed within the (now separate) product orgs.

While this is our target structure, you’ll find that these lines won’t be perfectly clear until the new year. At that time, Bhavana will have the opportunity to focus completely on Firefox OS 1.3 convergence after passing the baton of desktop releases and Metro (post-launch) to Lukas.

It’s only been a couple of years since Mozilla had a single major product focus and one release manager. Now we have a solid and growing team, even bringing community into the fold! Thanks to the team for making this possible.

Winqual is a site and service provided by Microsoft that enables us to look at data collected from Microsoft Windows Error Reporting (WER). If you’ve ever run into a Firefox crash/hang, seen something like

and clicked “Send Error Report”, your crash was reported to Microsoft and made available to Mozilla through the Winqual website.

Why should we care?

Any data that goes through WER is not currently making it into our crash reporting system, which makes it difficult for us to use our normal processes and weigh these issues against those already being tracked internally. Additionally, we know that there are some blind spots in our current crash reporting (for instance hangs) which Winqual does have additional information for.

The Plan

Our goals are to

1. Identify major issues in Firefox being reported through WER, and fix them
2. Find out why these crashes aren’t being caught by Crash Reporter, and fix those bugs as well
3. Address the fact that hangs are not currently going through our crash system by resolving bug 429592

The first two goals have some caveats as to how we can handle the Winqual data and conduct our investigation due to Microsoft’s terms. Only Mozilla employees can access the Winqual site, crash dumps, and data that is pulled from those dumps (such as a backtrace).

In order to make forward progress despite these stipulations, our plan is to give a subset of our crash kill team access to Winqual and the associated crash dumps, and have them file bugs into a new Firefox Bugzilla component called “Winqual Reports”. The bugs within this component will unfortunately need to be hidden. Once the investigation has progressed far enough to identify a reproducible case or fix, the implementation will be tracked in a second bug viewable by all.

We understand that this bug strategy is a deviation from the norm, but we also feel that the issues currently tracked in Winqual are important enough to follow up on. Please feel free to ask any questions you may have in the comments below. Thanks!

We’re looking to build a diverse community of Mozillians (staff and volunteers) who will come together to test nightly builds of Firefox for Android, file bugs, and provide regular feedback. We’ll be teaching everybody involved how to test and file bugs through a set of simple tutorials, and there will be plenty of opportunities to ask questions.

The initial focus of this program, much like the mobile refresh, will be on small form factor devices. We’ll have a (limited) supply of Android phones available for Mozilla staff and volunteers who don’t already have an Android phone.

For Americans in the audience, Thanksgiving is a time for giving – so please consider joining us and giving your time to the MTD cause. For everybody else, just look into this fox’s eyes and try to tell him no…

Sign up now!

There’s been a desire to put out Aurora release notes starting next week. That makes this a fantastic time to rethink the release notes, their audience, and their purpose. For an example of what we’re currently using, you can take a look at the 8.0 beta release notes.

We’ve identified a few issues with the current notes (after the break)

• [content] The two parts of the notes that are most important for a specific release, “What’s New” and “Known Issues”, are hidden behind “+” drop-downs.
• [content] There’s likely too much info on the page, and the info doesn’t appear to be updated as much as link alternatives.
• [audience] It’s unclear who the audience for these notes are, as some of the “Frequently Asked Questions” seem geared towards new Firefox users while the “Troubleshooting” section suggests a user opens up Terminal to debug their issues.
• [audience] Within the “What’s New” section a user who is specifically interested in user features or major bug fixes or new technologies cannot quickly parse the text.
• [implementation] The content of the release notes are currently copy/pasted from one note to another in order to maintain the format and carry over unresolved issues.
• [purpose] The current beta notes do suggest that users provide feedback through input.mozilla.com and Bugzilla, but don’t regularly leverage pre-release users for specific tasks.

The changes we’re currently pursuing are

• [content] We’re redesigning and branding the notes in bug 697337. See that bug for an initial mockup.
• [content] We’ll be culling the number of sections in the notes down to a more manageable set.
• See my proposal for editing in this image (forgive the roughness). Proposed main headings are “What’s New”, “Known Issues”, “Try Firefox”, “Having Problems?”, and “Get Involved”.
• [audience] Non-release channel notes will have different content than our release version – there will be more mention of how testers can utilize engineering tools like Bugzilla (see the last [purpose] bullet).
• [audience] We plan to start categorizing individual items in “What’s New” with tags like “New”, “Changed”, “Fixed”, and other technology-specific tags (think “HTML5″).
• [implementation] We’re going to start maintaining a common data source across all notes (a database of changes/issues).
• See bug 697519 for implementation details. This means we can automatically roll over unresolved bugs from release to release unless they’re marked otherwise. We’ll also be able to query release info and noted issues, which gets interesting in this next bullet.
• [purpose] Because we’re moving to a DB model, when a previously known issue is resolved, all older release notes will automatically link to the Firefox version where that issue was resolved. Value add!
• [purpose] Help curate the bug filing experience for community testers when additional testing is requested through the use of predefined file links.
• For instance “Please consider filing a technical bug report if you run into an issue when using the new animated tab functionality” which basically sets the following parameters automatically
• Product: Firefox
• Component: Tabbed Browser
• Version: 10 Branch
• Comment: “Steps to reproduce your animated tab issue:…”
• (hidden) Keyword: relnote_originated
• That hidden keyword is especially useful in case this experiment fails and teams need to filter out relnote bugs in their triage queries.

If the new notes are considered successful, we plan to roll out similar changes to Beta on the next merge date, and then Release 6 weeks after that.  If you’ve got any ideas for making release notes more useful, please share in the comments here or in the bugs listed above. Additionally, if you have any ideas for the best place to source release notes from, or a new process with which Mozillians can propose notes, please share.

Source on GitHub

To Install the Service

1. Open Finder
2. Shift+cmd+g to ~/Library/
3. Go to Services (create the folder if necessary)
4. Unzip “BugParser.zip” into that folder (you should now see BugParser.service in that directory)
5. Log-out and back in or run the following at the commandline

   /System/Library/CoreServices/pbs

6. Go to System Preferences, the Keyboard Pane, Services and find “Open in Bugzilla”
7. Click the checkbox to enable the service, and double-click to the right of the label to set a keyboard shortcut
8. Now select some text and hit your keyboard shortcut to launch Bugzilla in the default web browser. Here’s a random copy/paste for you to try it out on:

   Page 1 | Sep 27, 2011
   649234     nor     --     Wind     nobody@mozilla.org     UNCO     ---
   652021     nor     --     All     nobody@mozilla.org     NEW     ---
   652023     nor     --     All     nobody@mozilla.org     NEW     ---
   652024     nor     --     All     nobody@mozilla.org     NEW     ---
   652026     nor     --     All     nobody@mozilla.org     NEW     ---
   657697     nor     --     All     ddahl@mozilla.com     NEW     ---
   657699     nor     --     All     ddahl@mozilla.com     NEW     ---
   657700     nor     --     All     ddahl@mozilla.com     NEW     ---
   660091     nor     --     All     ddahl@mozilla.com     NEW     ---
   661052     nor     --     All     nobody@mozilla.org     NEW     ---
   661701     nor     --     Linu     nobody@mozilla.org     UNCO     ---
   666147     nor     --     Wind     nobody@mozilla.org     UNCO     ---
   673621     enh     --     All     nobody@mozilla.org     NEW     ---
   673955     min     --     Mac     nobody@mozilla.org     UNCO     ---
   686290     nor     --     Wind     nobody@mozilla.org     UNCO     ---