On Wed, Apr 19 2017, Clark Boylan wrote: > I think we know from experience that just stopping (eg reverting to the > situation we had before requirements and constraints) would lead to > sadness. Installations would frequently be impossible due to some > unresolvable error in dependency resolution. Do you have some > alternative in mind? Perhaps we loosen the in project requirements and > explicitly state that constraints are known to work due to testing and > users should use constraints? That would give users control to manage > their own constraints list too if they wish. Maybe we do this in > libraries while continuing to be more specific in applications?
Most of the problem that requirements is trying to solve is related to upper-constraints, blocking new releases. And this upper constraints are used in most jobs, preventing most failure that are seen in gates. It would have "covered" the pbr issue. What I want to stop here, is the automatic push of blacklisting/capping of stuff to *everything* in OpenStack as soon as one project have a problem with something. > I don't have all the answers, but am fairly certain the situation we > have today is better than the one from several years ago. It is just not > perfect. I think we are better served by refining the current setup or > replacing it with something better but not by reverting. Agreed, I'm not suggesting to revert everything. Just the automatic push of random requirements limits and binding to Oslo. And other projects if you like, we don't do it for a good year anymore in Telemetry, and again here we saw 0 breakage due to that change. Just more easyness to install stuff. -- Julien Danjou -- Free Software hacker -- https://julien.danjou.info
signature.asc
Description: PGP signature
__________________________________________________________________________ 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