From MozillaWiki
Jump to: navigation, search
  1. Summary of the last meeting.
  2. We have a lot of webservice methods and endpoints marked as EXPERIMENTAL and UNSTABLE.
    • STABLE/UNSTABLE in this context refers to the API design itself (names, parameters, results), not the stability of the code itself.
    • The entire REST endpoint is tagged as EXPERIMENTAL.
    • There appear to be no rules around when a method is upgraded to STABLE, resulting in this never happening.
    • Decision:
      • Make all current API endpoints (XML-RPC, JSON-RPC, RESTv1, BzAPI-compat) STABLE but deprecated, as none of them are going to change any more.
      • BMO workweek team to draw up a proposal for an API transitioning document to lead us to the promised land of RESTv2, the one API to rule them all.
      • Deprecation statements will link to the transition plan so users can decide which API to use in the mean time.
      • In the future, the REST API v2 will have API versioning in the URL, which makes all this different.
  3. Do we have a formal policy on how to handle security bugs, and when we do a point release based on them?
    • sgreen is concerned that the most recent security bug was a firedrill for BMO and BRC but still hasn't shipped in a security release.
    • A policy might help release managers make the case for the time necessary to do a firedrill.
    • dkl will draw up a proposed policy.
    • sgreen provided some suggestions for what it might say.
  4. What is our process surrounding the 5.0 release, especially regarding QA testing?
    • glob wants to know who is responsible for QAing 5.0.
    • dkl is hoping to get the QA scripts working again.
    • Gerv suggested that BzAPI would be a good source of tests, but it turned out that it isn't, really.
    • Steps to a release candidate:
      • Get 4.5.5 out of the door
      • Create a 5.0 branch
      • Update the QA scripts so they pass (as well as add any new scripts)
      • Ship a release candidate!