RapidRelease/LandingPlan

Not all these will apply for every change, but all are worth considering and exploring before landing changes on mozilla-central as part of a rapid release program. As part of rapid release, its critical to defend trunk development against half-baked changes, and any change that can't be fully functional, secure, localized, performant, and compatible by the end of a short release cycle.

Code completeness

• How functionally complete is the set of changes?
• Is there a back-out strategy for every change that is already to go?
• What's the state of string changes for the feature?
  • Are all strings changes completed?
    • Reviewed by UI/UX/L10n teams?
  • Is additional UI/UX/String work expected after experimental or beta testing?

Testing

• Try builds made?
• Are new test cases ready for the landing?
• How much test coverage is provided with existing, and new tests?
• What are the gaps that need to be filled in with extra test coverage?
• How much time has been invested in pre-landing test execution?
  • Have test been run, have results be analyzed, and have there been any impacts observed on:
  • performance -- start up, page loading, chrome interaction
  • memory use, leaks, disk footprint, and install package size
  • compatibility
    • existing web
    • web standards
    • addons and plugins and third party components general and binary compatiblity?
    • will any evangelism outreach be needed? has it started?
  • How much developer/community testing been completed?
  • Are bugs filed for any regressions?
• Is all the work, and any possible dependency work, completed?

Security

• What's the state of the design and implimentation security reviews?
  • have the reviews been completed or scheduled?
  • https://wiki.mozilla.org/Security/ReviewTemplate
  • Are any security risks introduced,
  • Have steps been taken to mitigate risks?
  • Are fuzzers needed, or have the been run?