All OSCI action items for prepare HCF check list has been done On Tue, Sep 9, 2014 at 6:27 PM, Mike Scherbakov <mscherba...@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 < > afedor...@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 < >> dborodae...@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 >>> <dmescherya...@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@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> -- >>> Dmitry Borodaenko >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Aleksandra Fedorova >> bookwar >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Mike Scherbakov > #mihgen > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev