On 20 April 2016 at 04:47, Clark Boylan <cboy...@sapwetik.org> wrote: > On Tue, Apr 19, 2016, at 08:14 AM, Doug Hellmann wrote: >> Excerpts from Jeremy Stanley's message of 2016-04-19 15:00:24 +0000: >> > On 2016-04-19 09:10:11 -0400 (-0400), Doug Hellmann wrote: >> > [...] >> > > We have the global list and the upper constraints list, and both >> > > are intended to be used to signal to packaging folks what we think >> > > ought to be used. I'm glad that signaling is working, and maybe >> > > that means you're right that we don't need to sync the list >> > > absolutely, just as a set of "compatible" ranges. >> > [...] >> > >> > When we were firming up the constraints idea in Vancouver, if my >> > memory is correct (which it quite often is not these days), part of >> > the long tail Robert suggested was that once constraints usage in >> > the CI is widespread we could consider resolving it from individual >> > requirements lists in participating projects, drop the version >> > specifiers from the global requirements list entirely and stop >> > trying to actively synchronize requirement version ranges in >> > individual projects. I don't recall any objection from those of us >> > around the table, though it was a small ad-hoc group and we >> > certainly didn't dig too deeply into the potential caveats that >> > might imply. >> >> I have no memory of that part of the conversation, but I'll take your >> word for it. >> >> If I understand your description correctly, that may be another >> alternative. Most of the reviews I've been doing are related to the >> constraints, though, so I'm not really sure it lowers the amount of work >> I'm seeing. > > This was one of my concerns with constraints when we put them in place. > Previously we would open requirements and things would break > periodically and we would address them. With constraints every single > requirements update whether centralized or decentralized needs to be > reviewed. It does add quite a bit of overhead. > > The argument at the time was that the time saved by not having the gate > explode every few weeks would offset the cost of micromanaging every > constraint update.
I also argued at the time that we should aim for entirely automated check-and-update. This has stalled on not figuring out how to run e.g. Neutron unit tests against requirements changes - our coverage is just too low at the moment to proceed further down the automation path. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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