On 06/25/2015 05:39 PM, Tim Bell wrote: > > > On 25/06/15 09:49, "Thierry Carrez" <thie...@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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev