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.

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

Reply via email to