<div dir="ltr">Thanks Dmitry.<div>I'm walking through one of the proposed designs: <a href="https://review.openstack.org/#/c/96429/" target="_blank">https://review.openstack.org/#/c/96429/</a>,</div><div><a href="http://docs-draft.openstack.org/29/96429/4/check/gate-fuel-specs-docs/4590dac/doc/build/html/specs/5.1/access-control-master-node.html" target="_blank">http://docs-draft.openstack.org/29/96429/4/check/gate-fuel-specs-docs/4590dac/doc/build/html/specs/5.1/access-control-master-node.html</a><br>



</div><div><br></div><div>I've noticed a few things in the process which I'd propose for changing (let's keep this email thread to discuss process itself, and not the content of the blueprint, which I'll comment in a separate thread):</div>



<div><ol><li>It is unclear who are mandatory people to review the blueprint.<br>For example, we have two +1th in the review, can I merge it now? Probably not... I think core developers need to come up with ideas who is mandatory to review a design, and put their names into changeset. For any feature, we must have QA lead approving it (whether QA lead reviews it itself, or puts +1 on behalf of other QA team expert. In the latter case, that person has to be in a list of reviewers.)</li>



<li>As we want to have more agile-like model with 2 week iterations, in order to get feedback sooner on where we are in the release cycle and keep some teams working on stuff which will come up in the release after current one, then it makes sense to split the work onto iterations. It is great to see that this design reflects multiple stages, which can be considered as iterations. I'm not sure that every stage can fit into 2 week cycle, but that's what I would love to achieve - when we have a clear scope for every iteration, and ability to re-arrange things after every iteration. See proposed schedule with iterations at <a href="https://wiki.openstack.org/wiki/Fuel/5.1_Release_Schedule" target="_blank">https://wiki.openstack.org/wiki/Fuel/5.1_Release_Schedule</a><br>



</li><li>While I'm Ok with anyone ++ing review request while it's not yet completed, I don't think mandatory core reviewer should do that - and I'd suggest that core reviewer should rather -1 it, providing comments and marking areas which are not yet complete. In this particular review we have few sections empty.</li>



</ol><div>Anyone has an opinion on this?</div></div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 5:35 AM, Dmitry Pyzhov <span dir="ltr"><<a href="mailto:dpyzhov@mirantis.com" target="_blank">dpyzhov@mirantis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Guys,<div><br></div><div>from now on we should keep all our 5.1 blueprint specs in one place: <a href="https://github.com/stackforge/fuel-specs" target="_blank">fuel-specs repo</a>. We do it same way as nova, so you can use <a href="https://wiki.openstack.org/wiki/Blueprints#Nova" target="_blank">their instruction</a> as a guideline.</div>


<div><br></div><div>Once again. All specifications for 5.1 blueprints need to be moved to stackforge. Here is example link: <a href="https://github.com/stackforge/fuel-specs/blob/master/specs/template.rst" target="_blank">https://github.com/stackforge/fuel-specs/blob/master/specs/template.rst</a>.</div>


<div><br></div><div>Jenkins builds every request and adds link to html docs to the comments. For example: <a href="https://review.openstack.org/#/c/96145/" target="_blank">https://review.openstack.org/#/c/96145/</a>. </div>

<div><br></div>
<div>I propose to send feedback for this workflow into this mailing thread.</div><div><br></div><div>Also, take a look on <a href="https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria" target="_blank">review guidelines</a>. It contains some useful information, you know.</div>


</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>Mike Scherbakov<br>#mihgen<br><br>
</div>