<div dir="ltr">Andrew,<div>thanks for pointing this out. Engineering in Europe has code review in priority #1 after fixing critical issues which block us from further testing.</div><div><br></div><div>Overall, I think it should be simple. If developer didn't push the crowd to review the patch linked to Low/Medium bug, and it didn't get merged by SCF - then it should be moved to next milestone. SCF by its definition means that code has to be in master for Low / Medium bugs, not on review.</div>
<div><br></div><div>Considering the fact that we have so many patches on review, I can propose the following:</div><div><ol><li>Actively ping each other to get those reviewed and merged</li><li>We can do an exception for those which have at least one +1 from some developer, but were not addressed by core developer. In this case we can allow the core developer to review and merge such patches by the end of the week.</li>
</ol><div>What we are trying to achieve is to limit the code flow into the master, so avoiding possible regressions which could be introduced by Low/Medium bug fixes.</div></div><div><br></div><div>Would it work?</div><div>
<br></div><div>Thanks,</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 22, 2014 at 9:03 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Mike,<div><br><div>I don't think we should SCF until the review queue is addressed, there are far to many outstanding reviews presently. I'm not saying the queue has to be flushed and revised (although we should give this time given the size of the outstanding queue) , but all patches should be reviewed, and merged, or minused (addressed). They should not be penalized because they are not high priority and no one has gotten around to reviewing them.</div>
</div><div><br></div><div>my though is: prior to SCF, the low and medium priority reviews must be addressed, and the submitter should have one additional day to revise the patch prior to their code being barred from the release. We could address this by having a review deadline the day prior to SCF, or watch excepted intently for revision the day after SCF.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Jul 22, 2014 at 8:08 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi Fuelers,<div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px">
Looks like we are more or less good to call for a Soft Code Freeze [1] on Thursday.</div>
<div style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<br></div><div style="font-family:arial,sans-serif;font-size:12.800000190734863px"><div>Then hard code freeze [2] will follow. It is planned to have no more than 2 weeks between SCF and HCF [3]. When hard code freeze is called, we create stable/5.1 branch at the same time to accept only critical bug fixes, and release will be produced out of this branch. At the same time master will be re-opened for accepting new features and all types of bug fixes.</div>
<div><br></div></div><div>[1] <a href="https://wiki.openstack.org/wiki/Fuel/Soft_Code_Freeze" style="font-size:12.800000190734863px;font-family:arial,sans-serif" target="_blank">https://wiki.openstack.org/wiki/Fuel/Soft_Code_Freeze</a></div>
<div>[2] <a href="https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze" style="font-family:arial,sans-serif;font-size:12.800000190734863px" target="_blank">https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze</a></div>
<div>
<font color="#222222">[3] <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></font></div><div><font color="#222222"><br></font></div>
<div><font color="#222222">Let me know if anything blocks us from doing SCF on 24th.</font></div>
<div><font color="#222222"><br></font></div><div><font color="#222222">Thanks,</font></div><span><font color="#888888"><div>-- </div><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</font></span></div></div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Andrew<div>Mirantis</div><div>Ceph community</div></div>
</font></span></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><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div>