On 25 June 2015 at 09:58, Thierry Carrez <thie...@openstack.org> wrote: > Joe Gordon wrote: >> On Wed, Jun 24, 2015 at 10:04 AM, Ed Leafe <e...@leafe.com >> <mailto:e...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
