I totally agree with Andrew. On Tuesday, February 3, 2015, Andrew Woodward <xar...@gmail.com> wrote:
> Either we do specs, or we don't. Either every one has to land their specs > before code or no one does. Its that simple. > > What should be sorted out? It is unavoidable that people will comment and >> ask questions during development cycle. >> I am not sure that merging spec as early as possible, and than add >> comments and different fixes is good strategy. >> On the other hand we need to eliminate risks.. but how merging spec can >> help? > > > The spec defining what has been committed already needs to be merged, and > we can open another review to modify the spec into another direction if > necessary. > > We can spend several month on polishing the spec, will it help >> to release feature in time? I don't think so. > > > The spec doesn't have to be perfect, but it needs to be merged prior to > code describing it. > > I think the spec should be a synchronization point, where different >> teams can discuss details and make sure that everything is correct. >> The spec should represent the current state of the code which is >> merged and which is going to be merged. > > > This isn't the intent of the spec, its to document the extent, general > direction, and impact of a feature. As a side effect, well defined specs > can also serve as documentation for the feature. While the discussion is > common on the spec, this should be done on a merged spec. > > On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L <e...@mirantis.com > <javascript:_e(%7B%7D,'cvml','e...@mirantis.com');>> wrote: > >> Hi, >> >> +1 to Dmitriy's comment. >> We can spend several month on polishing the spec, will it help >> to release feature in time? I don't think so. >> Also with your suggestion we'll get a lot of patches over 2 thousands >> lines of code, after spec is merged. Huge patches reduce quality, >> because it's too hard to review, also such patches much harder >> to get merged. >> I think the spec should be a synchronization point, where different >> teams can discuss details and make sure that everything is correct. >> The spec should represent the current state of the code which is >> merged and which is going to be merged. >> >> Thanks, >> >> On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak <dshul...@mirantis.com >> <javascript:_e(%7B%7D,'cvml','dshul...@mirantis.com');>> wrote: >> >>> Andrew, >>> What should be sorted out? It is unavoidable that people will comment >>> and ask questions during development cycle. >>> I am not sure that merging spec as early as possible, and than add >>> comments and different fixes is good strategy. >>> On the other hand we need to eliminate risks.. but how merging spec can >>> help? >>> >>> On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward <xar...@gmail.com >>> <javascript:_e(%7B%7D,'cvml','xar...@gmail.com');>> wrote: >>> >>>> Vova, >>>> >>>> Its great to see so much progress on this, however it appears that we >>>> have started merging code prior to the spec landing [0] lets get it >>>> sorted ASAP. >>>> >>>> [0] https://review.openstack.org/#/c/113491/ >>>> >>>> On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin <vkuk...@mirantis.com >>>> <javascript:_e(%7B%7D,'cvml','vkuk...@mirantis.com');>> wrote: >>>> > Hi, Fuelers and Stackers >>>> > >>>> > I am glad to announce that we merged initial support for granular >>>> deployment >>>> > feature which is described here: >>>> > >>>> > >>>> https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks >>>> > >>>> > This is an important milestone for our overall deployment and >>>> operations >>>> > architecture as well as it is going to significantly improve our >>>> testing and >>>> > engineering process. >>>> > >>>> > Starting from now we can start merging code for: >>>> > >>>> > >>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization >>>> > >>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing >>>> > >>>> > We are still working on documentation and QA stuff, but it should be >>>> pretty >>>> > simple for you to start trying it out. We would really appreciate your >>>> > feedback. >>>> > >>>> > Existing issues are the following: >>>> > >>>> > 1) pre and post deployment hooks are still out of the scope of main >>>> > deployment graph >>>> > 2) there is currently only puppet task provider working reliably >>>> > 3) no developer published documentation >>>> > 4) acyclic graph testing not injected into CI >>>> > 5) there is currently no opportunity to execute particular task - >>>> only the >>>> > whole deployment (code is being reviewed right now) >>>> > >>>> > -- >>>> > Yours Faithfully, >>>> > Vladimir Kuklin, >>>> > Fuel Library Tech Lead, >>>> > Mirantis, Inc. >>>> > +7 (495) 640-49-04 >>>> > +7 (926) 702-39-68 >>>> > Skype kuklinvv >>>> > 45bk3, Vorontsovskaya Str. >>>> > Moscow, Russia, >>>> > www.mirantis.com >>>> > www.mirantis.ru >>>> > vkuk...@mirantis.com >>>> <javascript:_e(%7B%7D,'cvml','vkuk...@mirantis.com');> >>>> > >>>> > >>>> __________________________________________________________________________ >>>> > 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 >>>> > >>>> >>>> >>>> >>>> -- >>>> Andrew >>>> Mirantis >>>> Ceph community >>>> >>>> On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin <vkuk...@mirantis.com >>>> <javascript:_e(%7B%7D,'cvml','vkuk...@mirantis.com');>> wrote: >>>> > Hi, Fuelers and Stackers >>>> > >>>> > I am glad to announce that we merged initial support for granular >>>> deployment >>>> > feature which is described here: >>>> > >>>> > >>>> https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks >>>> > >>>> > This is an important milestone for our overall deployment and >>>> operations >>>> > architecture as well as it is going to significantly improve our >>>> testing and >>>> > engineering process. >>>> > >>>> > Starting from now we can start merging code for: >>>> > >>>> > >>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization >>>> > >>>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing >>>> > >>>> > We are still working on documentation and QA stuff, but it should be >>>> pretty >>>> > simple for you to start trying it out. We would really appreciate your >>>> > feedback. >>>> > >>>> > Existing issues are the following: >>>> > >>>> > 1) pre and post deployment hooks are still out of the scope of main >>>> > deployment graph >>>> > 2) there is currently only puppet task provider working reliably >>>> > 3) no developer published documentation >>>> > 4) acyclic graph testing not injected into CI >>>> > 5) there is currently no opportunity to execute particular task - >>>> only the >>>> > whole deployment (code is being reviewed right now) >>>> > >>>> > -- >>>> > Yours Faithfully, >>>> > Vladimir Kuklin, >>>> > Fuel Library Tech Lead, >>>> > Mirantis, Inc. >>>> > +7 (495) 640-49-04 >>>> > +7 (926) 702-39-68 >>>> > Skype kuklinvv >>>> > 45bk3, Vorontsovskaya Str. >>>> > Moscow, Russia, >>>> > www.mirantis.com >>>> > www.mirantis.ru >>>> > vkuk...@mirantis.com >>>> <javascript:_e(%7B%7D,'cvml','vkuk...@mirantis.com');> >>>> > >>>> > >>>> __________________________________________________________________________ >>>> > 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 >>>> > >>>> >>>> >>>> >>>> -- >>>> Andrew >>>> Mirantis >>>> Fuel community ambassador >>>> Ceph community >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >>>> >>> >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >>> >> >> __________________________________________________________________________ >> 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 >> >> > > > -- > Andrew > Mirantis > Fuel community ambassador > Ceph community > -- Andrey Danin ada...@mirantis.com skype: gcon.monolake
__________________________________________________________________________ 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