<div dir="ltr">I believe that we need to do this, and agree with Vitaly.<div><br></div><div>Basically, when we are getting low amount of review requests, it's easy enough to do backports to stable branch. So criteria should be based on this, and I believe it can be even more soft, than what Vitaly suggests.</div><div><br></div><div>I suggest the following:</div><div>___</div><div>If no more than 3 new High / Critical priority bugs appeared in the passed day, and no more than 10 High/Critical over the past 3 days appeared - then stable branch can be created. ___</div><div><br></div><div>HCF criteria remain the same. We will just have stable branch earlier. It might be a bit of headache for our DevOps team: it means that</div><div><ul><li>6.1 ISO should appear immediately after first stable branch created (we need ISO and all set of tests working on master)<br></li><li>6.0 ISO has to be build on master branches from some repos, but stable/6.0 from other. Likely it means whether switching to stable/6.0 in fuel-main and hacking <a href="http://config.mk">config.mk</a>, or something else.</li></ul><div>DevOps team, what do you think?</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 14, 2014 at 5:24 PM, Vitaly Kramskikh <span dir="ltr"><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@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">There is a proposal to consider a repo as stable if there are no high/critical bugs and there were no such new bugs with this priority for the last 3 days. I'm ok with it.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-11-14 17:16 GMT+03:00 Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Guys,<br>
<br>
The idea of separate unfreezing is cool itself, but we have to define<br>
some rules how to define that fuel-web is stable. I mean, in fuel-web<br>
we have different projects, so when Fuel UI is stable, the<br>
fuel_upgrade or Nailgun may be not.<br>
<br>
- Igor<br>
<br>
On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh<br>
<div><div><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>> wrote:<br>
> Evgeniy,<br>
><br>
> That means that the stable branch can be created for some repos earlier. For<br>
> example, fuel-web repo seems not to have critical issues for now and I'd<br>
> like master branch of that repo to be opened for merging various stuff which<br>
> shouldn't go to 6.0 and do not wait until all other repos stabilize.<br>
><br>
> 2014-11-14 16:42 GMT+03:00 Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>>:<br>
>><br>
>> Hi,<br>
>><br>
>> >> There was an idea to make a separate code freeze for repos<br>
>><br>
>> Could you please clarify what do you mean?<br>
>><br>
>> I think we should have a way to merge patches for the next<br>
>> release event if it's code freeze for the current.<br>
>><br>
>> Thanks,<br>
>><br>
>> On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh<br>
>> <<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>> wrote:<br>
>>><br>
>>> Folks,<br>
>>><br>
>>> There was an idea to make a separate code freeze for repos, but we<br>
>>> decided not to do it. Do we plan to try it this time? It is really painful<br>
>>> to maintain multi-level tree of dependent review requests and wait for a few<br>
>>> weeks until we can merge new stuff in master.<br>
>>><br>
>>> --<br>
>>> Vitaly Kramskikh,<br>
>>> Software Engineer,<br>
>>> Mirantis, Inc.<br>
>>><br>
>>> _______________________________________________<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>
>><br>
>><br>
>> _______________________________________________<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>
><br>
><br>
><br>
> --<br>
> Vitaly Kramskikh,<br>
> Software Engineer,<br>
> Mirantis, Inc.<br>
><br>
> _______________________________________________<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>
<br>
_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></div>
</div>
</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><div class="gmail_signature"><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div></div>
</div>