Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140909/afc30bc1/attachment.html>