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