On Fri, Jun 13, 2014 at 1:00 PM, Christopher Yeoh <cbky...@gmail.com> wrote: > On Fri, Jun 13, 2014 at 11:28 AM, Matt Riedemann > <mrie...@linux.vnet.ibm.com> wrote: >> On 6/12/2014 5:58 PM, Christopher Yeoh wrote: >>> On Fri, Jun 13, 2014 at 8:06 AM, Michael Still <mi...@stillhq.com >>> <mailto:mi...@stillhq.com>> wrote:
[Pretty heavy snipping to keep this reply short] >>> - API changes should have an associated spec >> To compare, this [2] is an example of something that is updating an >> existing API but I don't think warrants a blueprint since I think it falls >> into the 'generally ok' section of the API change guidelines. > > So really I see this a new feature, not a bug fix. Someone thought that > detail was supported when writing the documentation but it never was. The > documentation is NOT the canonical source for the behaviour of the API, > currently the code should be seen as the reference. We've run into issues > before where people have tried to align code to the fit the documentation > and made backwards incompatible changes (although this is not one). > > Perhaps we need a streamlined queue for very simple API changes, but I do > think API changes should get more than the usual review because we have to > live with them for so long (short of an emergency revert if we catch it in > time). This is what I am getting at... It is sometimes hard to tell if an API change needs a spec or is a bug fix. The implications of making a mistake are large and painful. That's why I think we should push _every_ API change through the spec process. If its deemed by the reviewers there to be a trivial change or bugfix, then the spec review should be super fast, right? I like removing the discretion here, because it will reduce our error rate. Michael -- Rackspace Australia _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
