Hi, I also think, that after release we should run restrospective and actually analyse how much reality differs from the spec. This will help us improve planning in the future.
> On 03 Feb 2015, at 22:15, Andrey Danin <[email protected]> wrote: > > I totally agree with Andrew. > > On Tuesday, February 3, 2015, Andrew Woodward <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?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 <[email protected]> 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 > > [email protected] > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Andrew > Mirantis > Fuel community ambassador > Ceph community > > > -- > Andrey Danin > [email protected] > skype: gcon.monolake > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer [email protected] __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
