On 6 August 2017 at 23:33, Akihiro Motoki <amot...@gmail.com> wrote: > 2017-08-07 11:59 GMT+09:00 Tony Breeds <t...@bakeyournoodle.com>: > > Hi All, > > So as you all know we've frozen the requirements repo and it will > > stay frozen until after all the cycle-with-milestones projects have > > stable/pike branches. That's pretty normal. > > > > The last couple of cycles we've seen issues with projects that crate > > stable/pike branches *after* we've thawed/re-opened requirements repo > > for $next_release. > > > > What happens is those projects are still stabilising for pike but > > getting requirements updates for queens. When they *do* branch for pike > > they quickly get a proposal-bot change which seems to take things > > backwards. This bad for (at least) a couple of reasons. > > > > 1. Those projects are testing against the wrong requirements > > 2. You end up with a patch release for $project that radically changes > > the requirements for $project. > > Yeah, totally agree the above. > > > > > So I need some help identifying which projects are going to fall into > > this scenario. The easy to identify ones are cycle-trailing and we can > > easily cope with that by as there are only 4 of them. My instinct tells > > me that many of the neutron (stadium?) and horizon-plugin projects will > > fall into this boat. > > I think neutron stadium and horizon plugin projects with > cycle-with-intermediary are potentially affected. > They tends to ship a final release (and cut a stable branch if necessary). > > I think we can easily list such projects for official projects. > It is not easy to do it for hosted projects as we don't know their > release models. > Do we want to take care of hosted projects? > > > The following is about official projects. > > According to the release repo, there is no *official* neutron stadium > projects with cycle-with-intermediary release model. > networking-hyperv (of the winstackers project) adopts > cycle-with-intermediary model and it looks affected. > > Grepping the release deliverables, *official* horizon plugin projects > with cycle-with-intermediary models are: > > $ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml` > | grep -v cycle-with-milestones | cut -d : -f 1 > deliverables/pike/cloudkitty-dashboard.yaml > deliverables/pike/ironic-ui.yaml > deliverables/pike/karbor-dashboard.yaml > deliverables/pike/magnum-ui.yaml > deliverables/pike/manila-ui.yaml > deliverables/pike/monasca-ui.yaml > deliverables/pike/senlin-dashboard.yaml > deliverables/pike/solum-dashboard.yaml > deliverables/pike/tacker-horizon.yaml > deliverables/pike/vitrage-dashboard.yaml > deliverables/pike/watcher-dashboard.yaml > deliverables/pike/zun-ui.yaml > > > In addition, regarding neutron stadium projects and horizon plugin > projects, > they also need to update the branch (from master to stable/pike) of > neutron or horizon repo > as they installs neutron or horizon using tox_install.sh > (in addition to the branch of requirements repo). > This needs to happen just after stable/pike branch of neutron or > horizon is created. >
The switch to cycle-with-milestone [1] for all projects under neutron governance (except neutron-lib and ovsdbapp that are libraries) was done with the explicit intent of avoiding the overdue cut of stable branches for the current release, which may lead to the exact problem that Tony stated here. [1] https://review.openstack.org/#/c/437699/ > > Thanks, > Akihiro > > > Once we know the scope of the affected projects we can work out how to > > thaw the requirements repo with minimum impact. The alternative is to > > have the requirements repo frozen for > 1 month which no one wants. > > > > Yours Tony. > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev