Open Stack

+1 on adding flow based criteria for HCF and Branching Point. Tracking
down how many bugs was reported in LP on a given day is a bit tricky,
so I think in both cases it would be easier to rely on flow of commits
(which after Soft Code Freeze becomes a direct indicator of how many
bugs are fixed per day).

For HCF, not having merged any code changes for 24 hours (on top of
meeting the bug count criteria) would be a solid proof of code
stabilization.

For Branching Point, the threshold has to be more relaxed, for
example, less than 10 commits across all our code repositories within
last 24 hours.

I agree that landing Juno packages right now is going be disruptive. I
continue to think that the only way to address this long term is to
have a parallel OpenStack master branch based Fuel/MOS build series.
What we need to achieve that is have 2 build series based on Fuel
master: one with Icehouse packages, and one with Juno, and, as Mike
proposed, keep our manifests backwards compatible with Icehouse. That
way, we can land changes unrelated to Juno into Fuel master and debug
them using the Icehouse based build series, and land changes needed
for Juno integration into the same Fuel master branch, and debug them
in Juno based build series.

In order to minimize impact of non Juno related changes on Juno
integration, we should minimize breakage of Icehouse based builds. Two
ways to address that problem would be to serialize landing of major
changes (so that only one feature at a time can be blamed for
breakage), and agressively revert changes that cause BVT failure if
they are not fixed within 24 hours.

As soon as Juno builds reach the same level of stability of Icehouse,
we can drop the Icehouse based builds and introduce Kilo based builds
instead.

Thoughts?
-DmitryB


On Tue, Sep 9, 2014 at 7:27 AM, Mike Scherbakov
<mscherbakov at mirantis.com> wrote:
> Thanks Alexandra.
>
> We land a few patches a day currently, so I think we can open stable branch.
> If we see no serious objections in next 12 hours, let's do it. We would need
> to immediately notify everyone in mailing list - that for every patch for
> 5.1, it should go first to master, and then to stable/5.1.
>
> Is everything ready from DevOps, OSCI (packaging) side to do this? Fuel CI,
> OBS, etc.?
>
> On Tue, Sep 9, 2014 at 2:28 PM, Aleksandra Fedorova <afedorova at mirantis.com>
> wrote:
>>
>> As I understand your proposal, we need to split our HCF milestone into two
>> check points: Branching Point and HCF itself.
>>
>> Branching point should happen somewhere in between SCF and HCF. And though
>> It may coincide with HCF, it needs its own list of requirements. This will
>> give us the possibility to untie two events and make a separate decision on
>> branching without enforcing all HCF criteria.
>>
>> From the DevOps point of view it changes almost nothing, it just adds a
>> bit more discussion items on the management side and slight modifications to
>> our checklists.
>>
>>
>> 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
>>
>>
>>
>>
>> --
>> Aleksandra Fedorova
>> bookwar
>>
>> _______________________________________________
>> 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
>



-- 
Dmitry Borodaenko