Open Stack

On 14 June 2014 00:48, Michael Still <mikal at stillhq.com> wrote:
> 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.

Its super pain full when we screw up with API changes, particularly
with people deploying off trunk.

Are nova-specs average turnaround times fast enough for this right
now? Probably not. But thats a separate issue we really need to fix.

John