<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=koi8-r">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>+1. Not closing the spec process and alowing work to continue is good. Open Source works by allowing developers to scratch itches. If you impeed that itch scratching long enough they will go somewhere else to be able to meet their needs. The window between
 missed spec deadline and next open window is a very long time for that.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Maxim Nestratov<br>
<b>Sent:</b> Wednesday, June 24, 2015 11:58:20 AM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] [Nova] The unbearable lightness of specs<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">24.06.2015 20:21, Daniel P. Berrange пишет:<br>
> On Wed, Jun 24, 2015 at 04:46:57PM +0000, Michael Krotscheck wrote:<br>
>> On Wed, Jun 24, 2015 at 6:30 AM Matt Riedemann <mriedem@linux.vnet.ibm.com><br>
>> wrote:<br>
>><br>
>>> There is the openstack-specs repo for cross-project specs:<br>
>>><br>
>>> <a href="http://specs.openstack.org/openstack/openstack-specs/">http://specs.openstack.org/openstack/openstack-specs/</a><br>
>>><br>
>>> That'd be a good place for things like your os-vif library spec which<br>
>>> requires input from both nova and neutron teams, although I think it's<br>
>>> currently OK to have it in nova-specs since a lot of the forklift is<br>
>>> going to come from there and we can add neutron reviewers as needed.<br>
>><br>
>> Let's walk through a hypothetical (because I just went through this)<br>
>> example of a cross-project spec, assuming a 6 month release cycle (26<br>
>> weeks), assuming one person driving a spec.<br>
>><br>
>> First: Overhead<br>
>> - 1 week for vacation<br>
>> - 1 week for holidays.<br>
>> - 4 weeks for feature freeze.<br>
>> - 4 weeks of pre-summit roadmap planning.<br>
>> - 1 week of summit.<br>
>> Remaining: 15 weeks.<br>
>><br>
>> Second: Writing, discussing, and landing the spec.<br>
>> Remaining: 9 weeks.<br>
>><br>
>> Third: Role conflicts and internal overhead.<br>
>> Remaining time: 4.5 weeks<br>
>><br>
>> Writing the code:<br>
>> Remaining time: 3.5 weeks.<br>
>><br>
>> The last step: Getting the cores to agree with your approach.<br>
>> Remaining time: -0.5 weeks.<br>
>> The problem is how long it takes.<br>
> This ultimately comes back to what I think is a far too rigid and long<br>
> development cycle. The idea that we have to work through a process on<br>
> defined milestone dates across a 6 month window is really inflexible.<br>
> It is a process designed for project managers to micro-manage a team<br>
> of product developers, not a process designed for developers who are<br>
> capable of managing their own day to day workload in an open source<br>
> project.<br>
><br>
> At a minimum I'd like to see the specs review & approval completely<br>
> de-couple from the development cycle. There is really no compelling<br>
> reason why design reviews have to be put in a box against a specific<br>
> release. In doing so we create a big crunch at the start of each cycle,<br>
> which is what we're particularly suffering under this week and last.<br>
> We should be happy to review and approve specs at any time whatsoever,<br>
> and allow approval to last for at least 1 year (with caveat that it<br>
> can be revoked if something in nova changes to invalidate a design<br>
> decision).<br>
Absolutely agree. There is no use in waiting for another cycle to start <br>
if you missed deadline for your spec in current cycle. Why not to review <br>
specs and approve them setting next release cycle milestone and allow <br>
people to start coding and get code review for next release cycle?<br>
<br>
><br>
> More generally, I think that the 6 month release cycle is really harmful<br>
> to our development agility, and we'd actually increase the work<br>
> accomplished and smooth out the highs & lows of productivity  if we had<br>
> shorter cycles. This is something I suggested previously here<br>
><br>
>    <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html">
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html</a><br>
><br>
><br>
> Regards,<br>
> Daniel<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font>
</body>
</html>