RapidRelease/LandingPlan

From MozillaWiki
Jump to: navigation, search

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 tests 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?
  • What are the most serious outstanding bugs or or problems with the code that still need to be addressed?

Security

  • What's the state of the design and implimentation security reviews?