How to use "tracking" and "status" flags

[Benjamin Smedberg]

Now that we are in our first Aurora cycle and we have gotten the bug
flags set up for the new rapid release cycle, I'd like to describe in
more detail how these flags should be used. First, a brief description
of the flags:

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.

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.
* 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!

--BDS

[Robert O'Callahan]

On Tue, Apr 19, 2011 at 6:32 AM, Benjamin Smedberg <benj...@smedbergs.us>wrote:

> 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.
>

What about patches for new regressions in Firefox 4? Can they be considered
on a case by case basis?

Rob
--
"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]

[Sheila Mooney]

We are triaging the nominations list 3 times a week. There have been plenty
of bugs nominated tracking-firefox5=? that were regressions from Firefox 4
so they are being discussed on a case-by-case basis.

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.

Cheers,
Sheila

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

[Brian Smith]

Benjamin Smedberg wrote:
> * 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.

See https://bugzilla.mozilla.org/show_bug.cgi?id=513659

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?

- Brian

[Benjamin Smedberg]

To request approval for particular bugs, please use the appropriate flags.

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).

--BDS