<div dir="ltr">Currently I think we should take it as an exception, and discuss two points which I brought up. Obviously, if we open stable/5.1, then we are opening master for new features.<div><br></div><div>We will modify HCF definition once we settle on final decision.</div><div><br></div><div>Thanks,</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 1:02 PM, Igor Marnat <span dir="ltr"><<a href="mailto:imarnat@mirantis.com" target="_blank">imarnat@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>
just to clarify - do we want consider this as an exception, which is<br>
not going to be repeated next release? If not, we might want to<br>
consider updating the statement "It is the time when master opens for<br>
next release changes, including features." in [1]. If I got you<br>
correct, we are going to open master for development of new features<br>
now.<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze" target="_blank">https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze</a><br>
Regards,<br>
Igor Marnat<br>
<div><div><br>
<br>
On Tue, Sep 9, 2014 at 12:07 PM, Mike Scherbakov<br>
<<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>> wrote:<br>
> +1 to DmitryB, I think in this particular time and case we should open<br>
> stable/5.1. But not to call it HCF [1].<br>
><br>
> Though I think we should retrospect our approaches here.<br>
><br>
> Sometimes we can squash 30 bugs a day, and formally reach HCF. Though the<br>
> day after we will get 30 New bugs from QA. We might want to reconsider the<br>
> whole approach on criteria, and come up with "flow" instead. Like if we have<br>
> <=5 High bugs at the moment, and over last 3 days we were seeing <10<br>
> confirmed High/Critical bugs, then we can call for HCF (if 60 bugs in 3 last<br>
> days, then no way for HCF)<br>
> Consumption of new OpenStack release is hard and will be as such unless we<br>
> will be using Fuel in gating process for every patch being pushed to<br>
> OpenStack upstream. We want to deploy Juno now for 6.0, and the only way to<br>
> do it now - is to build all packages, try to run it, observe issues, fix,<br>
> run again, observe other issues... - and this process continues for many<br>
> iterations before we get stable ISO which passes BVTs. It is obvious, that<br>
> if we drop the Juno packages in, then our master is going to be broken.<br>
> If we do any other feature development, then we don't know whether it's<br>
> because Juno or that another feature. What should we do then?<br>
><br>
> My suggestion on #2 is that we could keep backward compatibility with<br>
> Icehouse code (on puppet side), and can continue to use BVT's, other testing<br>
> against master branch using both Icehouse packages and Juno. Thus we can<br>
> keep using gating process for fuel library, relying on stable Icehouse<br>
> version.<br>
><br>
> As for immediate action, again, I'm in favor of creating stable/5.1 in order<br>
> to unblock feature development in master, while we are fixing last issues<br>
> with OpenStack patching.<br>
><br>
> [1] <a href="https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze" target="_blank">https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze</a><br>
><br>
><br>
> On Tue, Sep 9, 2014 at 5:55 AM, Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> TL;DR: Yes, our work on 6.0 features is currently blocked and it is<br>
>> becoming a major problem. No, I don't think we should create<br>
>> pre-release or feature branches. Instead, we should create stable/5.1<br>
>> branches and open master for 6.0 work.<br>
>><br>
>> We have reached a point in 5.1 release cycle where the scope of issues<br>
>> we are willing to address in this release is narrow enough to not<br>
>> require full attention of the whole team. We have engineers working on<br>
>> 6.0 features, and their work is essentially blocked until they have<br>
>> somewhere to commit their changes.<br>
>><br>
>> Simply creating new branches is not even close to solving this<br>
>> problem: we have a whole CI infrastructure around every active release<br>
>> series (currently 5.1, 5.0, 4.1), including test jobs for gerrit<br>
>> commits, package repository mirrors updates, ISO image builds, smoke,<br>
>> build verification, and swarm tests for ISO images, documentation<br>
>> builds, etc. A branch without all that infrastructure isn't any better<br>
>> than current status quo: every developer tracking their own 6.0 work<br>
>> locally.<br>
>><br>
>> Unrelated to all that, we also had a lot of very negative experience<br>
>> with feature branches in the past [0] [1], which is why we have<br>
>> decided to follow the OpenStack branching strategy: commit all feature<br>
>> changes directly to master and track bugfixes for stable releases in<br>
>> stable/* branches.<br>
>><br>
>> [0] <a href="https://lists.launchpad.net/fuel-dev/msg00127.html" target="_blank">https://lists.launchpad.net/fuel-dev/msg00127.html</a><br>
>> [1] <a href="https://lists.launchpad.net/fuel-dev/msg00028.html" target="_blank">https://lists.launchpad.net/fuel-dev/msg00028.html</a><br>
>><br>
>> I'm also against declaring a "hard code freeze with exceptions", HCF<br>
>> should remain tied to our ability to declare a release candidate. If<br>
>> we can't release with the bugs we already know about, declaring HCF<br>
>> before fixing these bugs would be an empty gesture.<br>
>><br>
>> Creating stable/5.1 now instead of waiting for hard code freeze for<br>
>> 5.1 will cost us two things:<br>
>><br>
>> 1) DevOps team will have to update our CI infrastructure for one more<br>
>> release series. It's something we have to do for 6.0 sooner or later,<br>
>> so this may be a disruption, but not an additional effort.<br>
>><br>
>> 2) All commits targeted for 5.1 will have to be proposed for two<br>
>> branches (master and stable/5.1) instead of just one (master). This<br>
>> will require additional effort, but I think that it is significantly<br>
>> smaller than the cost of spinning our wheels on 6.0 efforts.<br>
>><br>
>> -DmitryB<br>
>><br>
>><br>
>> On Mon, Sep 8, 2014 at 10:10 AM, Dmitry Mescheryakov<br>
>> <<a href="mailto:dmescheryakov@mirantis.com" target="_blank">dmescheryakov@mirantis.com</a>> wrote:<br>
>> > Hello Fuelers,<br>
>> ><br>
>> > Right now we have the following policy in place: the branches for a<br>
>> > release are opened only after its 'parent' release have reached hard<br>
>> > code freeze (HCF). Say, 5.1 release is parent releases for 5.1.1 and<br>
>> > 6.0.<br>
>> ><br>
>> > And that is the problem: if parent release is delayed, we can't<br>
>> > properly start development of a child release because we don't have<br>
>> > branches to commit. That is current issue with 6.0: we already started<br>
>> > to work on pushing Juno in to 6.0, but if we are to make changes to<br>
>> > our deployment code we have nowhere to store them.<br>
>> ><br>
>> > IMHO the issue could easily be resolved by creation of pre-release<br>
>> > branches, which are merged together with parent branches once the<br>
>> > parent reaches HCF. Say, we use branch 'pre-6.0' for initial<br>
>> > development of 6.0. Once 5.1 reaches HCF, we merge pre-6.0 into master<br>
>> > and continue development here. After that pre-6.0 is abandoned.<br>
>> ><br>
>> > What do you think?<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Dmitry<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>
>> Dmitry Borodaenko<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>
> Mike Scherbakov<br>
> #mihgen<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>
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"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div></div>