Open Stack

On 25/06/15 09:49, "Thierry Carrez" <thierry at openstack.org> wrote:

>Maxim Nestratov wrote:
>> 24.06.2015 20:21, Daniel P. Berrange пишет:
>>> On Wed, Jun 24, 2015 at 04:46:57PM +0000, Michael Krotscheck wrote:
>>>> 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.
>>> [...]
>>>
>>> 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?
>
>I totally agree that there is no reason to tie specs drafting, review &
>approval to the development cycle. In fact, most project teams don't.
>
>Now, Michael's example is a bit unrealistic -- cross-project specs
>aren't tied to release cycle at all, and you can certainly work on them
>during the 4 weeks of feature freeze or 4 weeks of pre-summit roadmap
>planning.
>
>I would even argue that those 8 weeks are the ideal time to draft and
>get early reviews on a spec : you can use the design summit at the end
>of them to close the deal if it still needs discussion, and start
>working on code the week after.

The operator community has also been generally positive on the specs
process. It has allowed a possibility for people without python skills to
give input on the overall approach being taken rather than needing to
review code. The approach, after all, from an operator mid cycle meetup
(blueprints on blueprints) combined with the nova specs proposal.

I’ve certainly had a few specs where the approach needed in-depth
discussion (one I remember clearly was the re-assign a project spec) and
to have waited till the code was written would have been a waste.

One of the problems that I’ve seen is with specs etiquette where people -1
because they have a question. This is a question of education rather than
a fundamental issue with the process.

>
>-- 
>Thierry Carrez (ttx)
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev