<div dir="ltr">I envision it in the following way:<div><ol><li>stable/6.0 is created for fuel-main along with stable branch for other repo, which is under consideration, like fuel-web</li><li>In stable/6.0 of fuel-main, <a href="http://config.mk">config.mk</a> should be changed to refer to stable/6.0 for one of the repos, like fuel-web. master branch is still used for all other repos</li><li>All our jobs (Fuel CI, system tests, etc.) are forked, like we do at HCF. One set should point to stable/6.0, another to master of fuel-main.</li><li>Mirror has to be created for 6.1 immediately too, as we are opening master for fuel-main</li><li>System tests should be analyzed for regression by QA or Dev team.</li><li>As other repos start satisfying criteria, we can simply change branch name in <a href="http://config.mk">config.mk</a></li></ol><div>> <span style="font-family:arial,sans-serif;font-size:12.8000001907349px">should we </span><span style="font-size:12.8000001907349px;font-family:arial,sans-serif">pass </span><a href="http://config.mk/" target="_blank" style="font-size:12.8000001907349px;font-family:arial,sans-serif">config.mk</a><span style="font-size:12.8000001907349px;font-family:arial,sans-serif"> variables from Jenkins side</span></div><div>I do not think we should change job configs. Let's do changes only in source code, otherwise we will end up with having two places for configuration.</div></div><div><br></div><div>This is pretty massive change, and it will require testing of infrastructure for possible fork in advance, and creating a separate checklists for it.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 3:31 PM, Aleksandra Fedorova <span dir="ltr"><<a href="mailto:afedorova@mirantis.com" target="_blank">afedorova@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mike,<br>
<br>
from DevOps point of view it doesn't really matter when we do<br>
branching. This is the process we need to perform anyway and this<br>
partial branching doesn't change too much for us.<br>
Although there might be several technical questions like:<br>
<br>
1) When we create /6.1 mirror?<br>
2) Should we create fuel-main repo branch before others or should we<br>
pass <a href="http://config.mk" target="_blank">config.mk</a> variables from Jenkins side?<br>
<br>
But it can be done one way or the other.<br>
<br>
The primary concern here is not the build process and its<br>
implementation, but the question how we are going to test the "early"<br>
patches.<br>
<br>
Right now we have unit tests and general nightly tests which are<br>
analyzed and managed by QA team. The fact that we can create set of<br>
6.1 system test jobs earlier in the process and even run them daily<br>
doesn't mean that there will be people to watch them and analyze their<br>
results. If we do early 6.1-branching while QA team is focused on 6.0<br>
release, who will be dealing with this additional workload?<br>
<br>
And if those 6.1 nightly system tests aren't checked properly, we get<br>
code merged to fuel-web for several weeks based on unit-tests only,<br>
which is generally a bad idea. Especially with current state of<br>
fuel-web repository with several projects in one.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Nov 24, 2014 at 3:01 AM, Dmitry Borodaenko<br>
<<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>> wrote:<br>
> 1. We discussed splitting fuel-web, I think we should do that before<br>
> relaxing code freeze rules for it.<br>
><br>
> 2. If there are high or critical priority bugs in a component during soft<br>
> code freeze, all developers of that component should be writing, reviewing,<br>
> or testing fixes for these bugs.<br>
><br>
> 3. If we do separate code freeze for current components, we should always<br>
> start with fuel-main, so that we can switch repos from master to stable one<br>
> at a time.<br>
><br>
> On Nov 17, 2014 4:08 AM, "Mike Scherbakov" <<a href="mailto:mscherbakov@mirantis.com">mscherbakov@mirantis.com</a>> wrote:<br>
>><br>
>> I believe that we need to do this, and agree with Vitaly.<br>
>><br>
>> Basically, when we are getting low amount of review requests, it's easy<br>
>> enough to do backports to stable branch. So criteria should be based on<br>
>> this, and I believe it can be even more soft, than what Vitaly suggests.<br>
>><br>
>> I suggest the following:<br>
>> ___<br>
>> If no more than 3 new High / Critical priority bugs appeared in the passed<br>
>> day, and no more than 10 High/Critical over the past 3 days appeared - then<br>
>> stable branch can be created. ___<br>
>><br>
>> HCF criteria remain the same. We will just have stable branch earlier. It<br>
>> might be a bit of headache for our DevOps team: it means that<br>
>><br>
>> 6.1 ISO should appear immediately after first stable branch created (we<br>
>> need ISO and all set of tests working on master)<br>
>> 6.0 ISO has to be build on master branches from some repos, but stable/6.0<br>
>> from other. Likely it means whether switching to stable/6.0 in fuel-main and<br>
>> hacking <a href="http://config.mk" target="_blank">config.mk</a>, or something else.<br>
>><br>
>> DevOps team, what do you think?<br>
>><br>
>><br>
>> On Fri, Nov 14, 2014 at 5:24 PM, Vitaly Kramskikh<br>
>> <<a href="mailto:vkramskikh@mirantis.com">vkramskikh@mirantis.com</a>> wrote:<br>
>>><br>
>>> There is a proposal to consider a repo as stable if there are no<br>
>>> high/critical bugs and there were no such new bugs with this priority for<br>
>>> the last 3 days. I'm ok with it.<br>
>>><br>
>>> 2014-11-14 17:16 GMT+03:00 Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>>:<br>
>>>><br>
>>>> 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>
>>>> <<a href="mailto:vkramskikh@mirantis.com">vkramskikh@mirantis.com</a>> wrote:<br>
>>>> > Evgeniy,<br>
>>>> ><br>
>>>> > That means that the stable branch can be created for some repos<br>
>>>> > earlier. For<br>
>>>> > example, fuel-web repo seems not to have critical issues for now and<br>
>>>> > I'd<br>
>>>> > like master branch of that repo to be opened for merging various stuff<br>
>>>> > 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">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">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<br>
>>>> >>> painful<br>
>>>> >>> to maintain multi-level tree of dependent review requests and wait<br>
>>>> >>> 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">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">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">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">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">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>
>> Mike Scherbakov<br>
>> #mihgen<br>
>><br>
>><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>
><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>
<br>
<br>
<br>
--<br>
</div></div><span class="HOEnZb"><font color="#888888">Aleksandra Fedorova<br>
Fuel Devops Engineer<br>
bookwar<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></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>