Open Stack

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
>