Development Policy for Stabilization Period

All Issue Tracking is Done in Bugzilla

New Gaia bugs should be filed in Bugzilla, under the Boot2Gecko product and the Gaia component
Enhancement requests (v2 work) should still be filed in Github
Existing Gaia blockers have been migrated to Bugzilla, with owners and labels intact.

All commits require:
- Blocking-basecamp+ or driver approval (see below)
- Unit or integration tests attached
- Confirmation that smoketests are not regressed
All other commits will be backed out.
Driver approval can be requested on the bug or on IRC from:
- Platform: Andrew Overholt, Chris Jones, Johnny Stenback, Jonas Sicking, Andreas Gal
- Gaia: Vivien Nicolas, Chris Jones, Francisco Jordano
- Any of the Release Management team (Alex Keybl, Lukas Blakk, Bhavana Bajaj)
- Miguel Schneider, Daniel Coloma, Chris Lee for product decisions
- To request driver approval on a patch for Gaia changes, set the approval-gaia-master flag to "?" and put one of the previously mentioned people in the field so that a specific person is asked. There is no approval triage like there is for blocking-basecamp. Setting the flag will create a template asking you for information, please fill it in.
- As we come closer to shipping, approval-gaia-master will be used for all landings (even if blocking+)

All commits now require:
- Unit or integration tests in the pull request or patch
- A commit message format of "Bug {bugNumber} - {summary} (r={reviewer})", or at least have all of those components included.
Devs are expected to have run their tests locally before submitting any code changes for review, and including the test files in the pull request.
If your commit message doesn't have all the required components, it will be backed out. The Gaia dev leads and the release drivers will be triaging the commit logs daily to ensure these requirements are followed.
Continuous integration + automated smoketests is being implemented at this moment and will be enabled as soon as possible. Once that happens, each and every commit will run all the tests and spit out a report letting you know if your change caused any test failures anywhere in the system.

The at-risk sheet: http://j.mp/VWpueM
If your feature is missing, and not on the sheet, ping a PM to have it added for evaluation
Anything large enough to need multiple followups or that risks causing many regressions is likely a feature
Features listed on the at-risk spreadsheet must have estimates for completion
Even these features need to land within approximately 14 days to not put our target deadline at risk

This means that anything landing in Gecko after 10/7 needs to land both on mozilla-central and mozilla-aurora (Firefox 18).
All patches landing on mozilla-aurora must go through the normal approval-mozilla-aurora:? triage - risk evaluations for desktop/mobile should be included