Now that we are in our first Aurora cycle and nearing our first Beta cycle (May 17), we are doing regular triage for both Aurora and now Beta.   There are three flags that are being used, they are:

tracking-firefoxN: ?, +, -

The tracking flag is used to alert release drivers of bugs which may need to be addressed during the release cycle.

During the mozilla-central portion of the release cycle, any major new features should also be nominated (currently by setting
tracking-firefox6:?). In addition, new regressions (functionality or stability) should be nominated. Tracking bugs are not necessarily
“blockers”: it merely means that release drivers will look at the bug  during the weekly triage sessions.  Please describe in a comment why you are nominating the bug for tracking, or the triage team may send it back for comment.

status-firefoxN: unaffected, affected, fixed

The status flag is used to track bugs for particular release cycles. I  hope that the values are pretty self-explanatory. The status flag is
only available once a release has branched for aurora: before that time, just use the bugzilla resolutions NEW/ASSIGNED or FIXED.

approval-mozilla-aurora and approval-mozilla-beta

These patch flags are used to mark changes which are approved for the  current aurora and beta release train. ALL changes in aurora and beta
require explicit approval, even backouts. This rule is in place so that release drivers know what is landing and can inform relevant stakeholders (addons, l10n, marketing, docs) of any feature changes that happen during stabilization.  A bug does not need to have the tracking flag set in order to get approval, but tracked bugs are more likely to get approval.  Please describe in a comment why you are nominating the bug for tracking and the risks associated with landing the patch or the triage team may send it back for comment.

FAQ:

* What are the approval criteria for landing on aurora (and beta)?

The only changes being accepted on aurora are backouts, trivial fixes for new regressions, and security/stability fixes. “new code” is not acceptable and should wait for the next release train. Patches which affect extension compatibility, localization, or APIs are generally not acceptable unless they are necessary backouts to fix critical issues. As the aurora period proceeds, approval requirements become much more stringent: by the time we
reach beta, builds are basically release candidates and only the most critical issues will be granted approval.

* How are security bugs handled?

The security team is responsible for triaging all tracking? and tracking+ security bugs and monitoring their progress in a separate triage meeting. The Aurora and Beta triage teams will be responsible for approving the patches for the security bugs as part of their regular triage process.

* I found a regression bug: what do I do?

Add the ‘regression’ keyword, as always. Set tracking-firefox6:? and tracking-firefox5:?. If we know that the bug affects aurora,
set status-firefox5:affected. If we don’t know what branches are affected, add the qawanted keyword.

* I want to back out a change from aurora because of issues that were found: what do I do?

Make sure a bug is on file. Set tracking-firefox5:? on the bug.  Attach a patch for the backout, or a text file indicating what `hg
backout` command will be used, and set approval-mozilla-aurora:?// on the patch/attachment.

Any additional questions, please ask on dev.planning.