Open Stack

> -----Original Message-----
> From: Nikola Đipanov [mailto:ndipanov at redhat.com]
> Sent: 26 June 2015 18:34
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs
> 
> 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.
> 

Limiting those who give input to the people who can analyse python and determine the impacts of the change has significant risks. Many of those running OpenStack clouds can give their feedback as part of the specs process. While this may not be as fully structured as you would like, ignoring the input from those who are running clouds when proposing a change is likely to cause problems later on. 

The specs process was developed jointly to allow exactly this kind of early input ... people writing the code wanted input from those who were using this code to deliver new functions and improvements to the end users of the cloud. No problem to discuss how to improve the process but it is important to allow all the people affected by a change to be involved in the solution and contribute, not just the ones writing the code.

Tim

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