Bugzilla:Meetings:2014-07-23
From MozillaWiki
- Summary of the last meeting.
- 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.
- 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.
- 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!
