Open Stack

On Fri, Jun 13, 2014 at 1:00 PM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> On Fri, Jun 13, 2014 at 11:28 AM, Matt Riedemann
> <mriedem at 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 <mikal at stillhq.com
>>> <mailto:mikal at 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