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