Open Stack

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 <imarnat at 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
> <mscherbakov at 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 <
> dborodaenko at 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
> >> <dmescheryakov at 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 at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >> --
> >> Dmitry Borodaenko
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Mike Scherbakov
> > #mihgen
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140909/9c242e01/attachment.html>