Landing plan on mozilla-central and quality

From MozillaWiki
Jump to: navigation, search

Warning: The content of this page is obsolete and kept for archiving purposes of past processes.

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?