Open Stack

On 25 June 2015 at 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.

+1

At the summit, I think we agreed to keep the backlog open for the
duration of liberty. So all new ideas flow into the backlog, post
"spec freeze".
https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#Dates_overview

Now we didn't agree the next bit.

I think thats something for the midcylce or a similar "high bandwidth"
medium. I like the idea of marking specs as complete when they get
released, matching what we now do with milestone pages. I am yet to
get chance to write up a proposal. I certainly intend to have a
concrete idea to review at the midcyle.

> 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.

We certainly reviewed and merge specs before the summit. The idea was
our summit sessions were focused on "stuck" spec reviews. It didn't
didn't totally work out that way.

Thanks,
John