[openstack-dev] [Nova] The unbearable lightness of specs

Maxim Nestratov mnestratov at virtuozzo.com
Wed Jun 24 18:58:20 UTC 2015


24.06.2015 20:21, Daniel P. Berrange пишет:
> On Wed, Jun 24, 2015 at 04:46:57PM +0000, Michael Krotscheck wrote:
>> On Wed, Jun 24, 2015 at 6:30 AM Matt Riedemann <mriedem at linux.vnet.ibm.com>
>> wrote:
>>
>>> There is the openstack-specs repo for cross-project specs:
>>>
>>> http://specs.openstack.org/openstack/openstack-specs/
>>>
>>> That'd be a good place for things like your os-vif library spec which
>>> requires input from both nova and neutron teams, although I think it's
>>> currently OK to have it in nova-specs since a lot of the forklift is
>>> going to come from there and we can add neutron reviewers as needed.
>>
>> Let's walk through a hypothetical (because I just went through this)
>> example of a cross-project spec, assuming a 6 month release cycle (26
>> weeks), assuming one person driving a spec.
>>
>> First: Overhead
>> - 1 week for vacation
>> - 1 week for holidays.
>> - 4 weeks for feature freeze.
>> - 4 weeks of pre-summit roadmap planning.
>> - 1 week of summit.
>> Remaining: 15 weeks.
>>
>> Second: Writing, discussing, and landing the spec.
>> Remaining: 9 weeks.
>>
>> Third: Role conflicts and internal overhead.
>> Remaining time: 4.5 weeks
>>
>> Writing the code:
>> Remaining time: 3.5 weeks.
>>
>> The last step: Getting the cores to agree with your approach.
>> Remaining time: -0.5 weeks.
>> The problem is how long it takes.
> This ultimately comes back to what I think is a far too rigid and long
> development cycle. The idea that we have to work through a process on
> defined milestone dates across a 6 month window is really inflexible.
> It is a process designed for project managers to micro-manage a team
> of product developers, not a process designed for developers who are
> capable of managing their own day to day workload in an open source
> project.
>
> At a minimum I'd like to see the specs review & approval completely
> de-couple from the development cycle. There is really no compelling
> reason why design reviews have to be put in a box against a specific
> release. In doing so we create a big crunch at the start of each cycle,
> which is what we're particularly suffering under this week and last.
> We should be happy to review and approve specs at any time whatsoever,
> and allow approval to last for at least 1 year (with caveat that it
> can be revoked if something in nova changes to invalidate a design
> decision).
Absolutely agree. There is no use in waiting for another cycle to start 
if you missed deadline for your spec in current cycle. Why not to review 
specs and approve them setting next release cycle milestone and allow 
people to start coding and get code review for next release cycle?

>
> More generally, I think that the 6 month release cycle is really harmful
> to our development agility, and we'd actually increase the work
> accomplished and smooth out the highs & lows of productivity  if we had
> shorter cycles. This is something I suggested previously here
>
>    http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html
>
>
> Regards,
> Daniel




More information about the OpenStack-dev mailing list