Open Stack

On 25 June 2015 at 09:58, Thierry Carrez <thierry at openstack.org> wrote:
> Joe Gordon wrote:
>> On Wed, Jun 24, 2015 at 10:04 AM, Ed Leafe <ed at leafe.com
>> <mailto:ed at leafe.com>> wrote:
>>> [...]
>>> Other emails have touched on the biggest disconnect in the process: that
>>> an approved spec magically becomes unapproved on a particular calendar
>>> date. This makes no sense whatsoever. If it was a good idea yesterday,
>>> it will almost always be a good idea tomorrow.
>>
>> I don' think this is a accurate summary of the status quo.
>>
>> We currently have the fast track process, where if a spec was previously
>> approved we will quickly re-approve it. (I do a git diff between the
>> previous version and make sure the diff is trivial). By my count in
>> liberty we successfully used this procedure around 14 times. So yes
>> things do magically become unapproved on a somewhat random date, but I
>> don't think this is realistically a major pain point. (Side note we were
>> able to approve a lot of those specs before the summit).
>>
>> Secondly nova is moves fast. For example in Kilo we had: 4752 files
>> changed, 299,275 insertions(+), 309,689 deletions(-) [0].  What is
>> amazing about this is nova kilo only had 251,965 lines [1].  So specs
>> that we approved 6 months ago are often not valid anymore, I have seen
>> this happen time and time again.
>
> Could you give specific examples ? Tying the specs to a specific cycle
> results in lots of overhead and extra pain. I understand it's meant to
> ensure that 6-month-old specs are still current, but the benefits may
> not outweigh the huge drawbacks.

I am sure we can find a much better trade off here.

> Is there any horror story that this
> process actually prevented ?

This cycle lots of specs submitters were told:
* no you can't add that to the v2 API now, its closed
* please instead add that to the v2.1 API as a new microversion
* good news, no need for a new extension, no need to implement your
feature for both v2 and v3

So the idea, was we can tell people about all the refactoring/changes
in the previous release that impacts their feature, before they start
coding, to save finding out after having written all their code.

Now a whole bunch of specs were just waved through as fine as they
are, usually quite quickly.

Was it worth that all the extra pain, for the smallish gain. Not sure.
Could change the process so its more lightweight (more optimistic) and
still get a lot of the benefits of the current blueprint refresh, I
hope so.

We have kinda blocked some specs where we think it would conflict with
priority efforts, and be much easier to maintain in the long run if we
merge it after those effort. Some of the API changes folks would like
to make, are an example of that.

Thanks,
John