Open Stack

On 06/25/2015 05:39 PM, Tim Bell wrote:
> 
> 
> 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.
> 

No doubt doing design prior to coding is extremely useful in a lot of
cases, and having documents/artifacts of that process in a well-known
place. Some problems don't need that much of design outside of code
itself though.

This is what I was referring to elsewhere on the thread when I said we
are coupling together the process of designing a feature with it's
approval for a release and release planning etc. and then blanket apply
it to everything that resembles a feature.

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

It's not only about education - I think Gerrit is the wrong medium to
have a design discussion and do design work. Maybe you disagree as you
seem to imply that it worked well in some cases?

I've recently seen on more than a few cases how a spec "review" can
easily spiral into a collection of random comments that are hard to put
together in a coherent discussion that you could call design work.

If you throw in the expectation of approval into the mix, I think it
basically causes the opposite of good design collaboration to happen.

N.