Open Stack

All OSCI action items for prepare HCF check list  has been done

On Tue, Sep 9, 2014 at 6:27 PM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140909/1a11585e/attachment.html>