Open Stack

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