On 13/01/16 19:27, Carl Baldwin wrote: > Hi, > > I was looking at the most recent gate breakage in Neutron [1], fixed > by [2]. This gate breakage was held off for some time by the > upper-constraints.txt file. This is great progress and I applaud it. > I'll continue to cheer on this effort. > > Now to the next problem. If my assessment of this gate failure is > correct, the update to the upper-constraints file [3] was merged > without running all of the tests across all of the projects that would > be broken by bringing in this new constraint. So, we still get > breakage and it is still (IMO) too often. > > As I see it, there are a couple of options. > > 1) We run all tests under the upper-constraints control on all updates > to the upper constraints file like [2]. This would probably mean each > update has a very long list of tests and we would require that they > all be fixed before the upper constraint update can be merged. This > seems like a difficult thing to coordinate all at once. > 2) We handle upper-constraints much like we do the global requirements > updates. We have the master and a bot that proposes updates to it out > to the individual projects. This would create a situation where > projects are out of sync with the master but I think if we froze the > master early enough, we could have time to reconcile before release. > 3) We continue to allow changes in the upper constraints to break > individual projects. > > Are there options that I missed? What is your opinion? In my > opinion, gate breakage happens a bit too often and the effect on the > community is widespread. I'd like to contain it even a little bit > more. > > Carl > > [1] https://bugs.launchpad.net/neutron/+bug/1533638 > [2] https://review.openstack.org/#/c/266885/ > [3] https://review.openstack.org/#/c/266042/
I've only just started to learn about requirements and constraints, so I may be misunderstanding. However, https://github.com/openstack/requirements/blob/master/README.rst says: > For upper-constraints.txt changes > > If the change was proposed by the OpenStack CI bot, then if the > change has passed CI, only one reviewer is needed and they should +2 > +A without thinking about things. > > If the change was not proposed by the OpenStack CI bot, and does not > include a global-requirements.txt change, then it should be rejected: > the CI bot will generate an appropriate change itself. Ask in > #openstack-infra if the bot needs to be run more quickly. Doesn't that mean that [3] should have been rejected, and hence already cover the recent situation? Neil __________________________________________________________________________ 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
