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 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.
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.
* 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.
* 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!
> 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
What about patches for new regressions in Firefox 4? Can they be considered
on a case by case basis?
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
If you nominate something, I encourage you to detail in the bug why this
simply cannot wait 6 weeks until the next train (this is one of the first
questions we ask). It's also helpful to detail the risks, what testing has
been done so far etc. Most of the bugs nominated so far have had little
detail explaining why they were nominated.
IPv6 test day is June 8, 2011. This bug will not affect many users until (except on) June 8, 2011. I think it would be good to fix it in a Firefox 4.0.x update before June. After that update, this bug would become a regression if we ship Firefox 5 without it. Acceptable?
If you are trying to discuss the general criteria using this particular
example: no, I would not take this patch into aurora at the present
time: we haven't got it landed on trunk yet, and although the patch
appears relatively safe, the benefit is also relatively modest. IPv6,
despite it's importance to the future web, is not deployed on most users
computers (at least in a way they can get access).