<div dir="ltr">>> The spec doesn't have to be perfect, but it needs to be merged prior to code describing it.<div><br></div><div>Currently the spec has to be perfect and detailed enough, otherwise you will have</div><div>to merge the spec with -1 from reviewers, also if you postpone the details,</div><div>you won't be able to track, if these details were fixed.</div><div>Also with your approach the terminology is going to be changed, because</div><div>ready spec != merged spec anymore.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 9:46 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.<span class=""><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle.<br>I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy.<br>On the other hand we need to eliminate risks.. but how merging spec can help?</blockquote><div> </div></span>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.<div><br></div><div><span class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">We can spend several month on polishing the spec, will it help<br>to release feature in time? I don't think so.</blockquote><div><br></div></span><div>The spec doesn't have to be perfect, but it needs to be merged prior to code describing it.</div><span class=""><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">I think the spec should be a synchronization point, where different<br>teams can discuss details and make sure that everything is correct.<br>The spec should represent the current state of the code which is<br><span style="font-size:12.8000001907349px">merged and which is going to be merged.</span> </blockquote><div><br></div></span><div>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. </div></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>+1 to Dmitriy's comment.</div><div>We can spend several month on polishing the spec, will it help</div><div>to release feature in time? I don't think so.</div><div>Also with your suggestion we'll get a lot of patches over 2 thousands</div><div>lines of code, after spec is merged. Huge patches reduce quality,</div><div>because it's too hard to review, also such patches much harder</div><div>to get merged.</div><div>I think the spec should be a synchronization point, where different</div><div>teams can discuss details and make sure that everything is correct.</div><div>The spec should represent the current state of the code which is</div><div>merged and which is going to be merged.</div><div><br></div><div>Thanks,</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Andrew,<div>What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle.</div><div>I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy.</div><div>On the other hand we need to eliminate risks.. but how merging spec can help?</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Vova,<br>
<br>
Its great to see so much progress on this, however it appears that we<br>
have started merging code prior to the spec landing [0] lets get it<br>
sorted ASAP.<br>
<br>
[0] <a href="https://review.openstack.org/#/c/113491/" target="_blank">https://review.openstack.org/#/c/113491/</a><br>
<div><div><br>
On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>> wrote:<br>
> Hi, Fuelers and Stackers<br>
><br>
> I am glad to announce that we merged initial support for granular deployment<br>
> feature which is described here:<br>
><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks" target="_blank">https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks</a><br>
><br>
> This is an important milestone for our overall deployment and operations<br>
> architecture as well as it is going to significantly improve our testing and<br>
> engineering process.<br>
><br>
> Starting from now we can start merging code for:<br>
><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization</a><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing</a><br>
><br>
> We are still working on documentation and QA stuff, but it should be pretty<br>
> simple for you to start trying it out. We would really appreciate your<br>
> feedback.<br>
><br>
> Existing issues are the following:<br>
><br>
> 1) pre and post deployment hooks are still out of the scope of main<br>
> deployment graph<br>
> 2) there is currently only puppet task provider working reliably<br>
> 3) no developer published documentation<br>
> 4) acyclic graph testing not injected into CI<br>
> 5) there is currently no opportunity to execute particular task - only the<br>
> whole deployment (code is being reviewed right now)<br>
><br>
> --<br>
> Yours Faithfully,<br>
> Vladimir Kuklin,<br>
> Fuel Library Tech Lead,<br>
> Mirantis, Inc.<br>
> <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904" target="_blank">+7 (495) 640-49-04</a><br>
> <a href="tel:%2B7%20%28926%29%20702-39-68" value="+79267023968" target="_blank">+7 (926) 702-39-68</a><br>
> Skype kuklinvv<br>
> 45bk3, Vorontsovskaya Str.<br>
> Moscow, Russia,<br>
> <a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br>
> <a href="http://www.mirantis.ru" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a><br>
><br>
</div></div>> __________________________________________________________________________<br>
<span>> OpenStack Development Mailing List (not for usage questions)<br>
</span>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Andrew<br>
Mirantis<br>
Ceph community<br>
<div><div><br>
On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>> wrote:<br>
> Hi, Fuelers and Stackers<br>
><br>
> I am glad to announce that we merged initial support for granular deployment<br>
> feature which is described here:<br>
><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks" target="_blank">https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks</a><br>
><br>
> This is an important milestone for our overall deployment and operations<br>
> architecture as well as it is going to significantly improve our testing and<br>
> engineering process.<br>
><br>
> Starting from now we can start merging code for:<br>
><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization</a><br>
> <a href="https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing" target="_blank">https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing</a><br>
><br>
> We are still working on documentation and QA stuff, but it should be pretty<br>
> simple for you to start trying it out. We would really appreciate your<br>
> feedback.<br>
><br>
> Existing issues are the following:<br>
><br>
> 1) pre and post deployment hooks are still out of the scope of main<br>
> deployment graph<br>
> 2) there is currently only puppet task provider working reliably<br>
> 3) no developer published documentation<br>
> 4) acyclic graph testing not injected into CI<br>
> 5) there is currently no opportunity to execute particular task - only the<br>
> whole deployment (code is being reviewed right now)<br>
><br>
> --<br>
> Yours Faithfully,<br>
> Vladimir Kuklin,<br>
> Fuel Library Tech Lead,<br>
> Mirantis, Inc.<br>
> <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904" target="_blank">+7 (495) 640-49-04</a><br>
> <a href="tel:%2B7%20%28926%29%20702-39-68" value="+79267023968" target="_blank">+7 (926) 702-39-68</a><br>
> Skype kuklinvv<br>
> 45bk3, Vorontsovskaya Str.<br>
> Moscow, Russia,<br>
> <a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a><br>
> <a href="http://www.mirantis.ru" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a><br>
><br>
</div></div>> __________________________________________________________________________<br>
<span>> OpenStack Development Mailing List (not for usage questions)<br>
</span>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Andrew<br>
Mirantis<br>
Fuel community ambassador<br>
Ceph community<br>
<br>
__________________________________________________________________________<br>
<span>OpenStack Development Mailing List (not for usage questions)<br>
</span>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Andrew<br>Mirantis<br>Fuel community ambassador <br>Ceph community</div>
</div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>