On 9 July 2015 at 00:02, Doug Hellmann <d...@doughellmann.com> wrote: > > Excerpts from Robert Collins's message of 2015-07-09 07:49:36 +1200: > > On 8 July 2015 at 21:01, Thierry Carrez <thie...@openstack.org> wrote: > > > Robert Collins wrote: > > >> We've finally gotten all the kinks worked out and now > > >> upper-constraints proposals should be coming in daily. > > >> > > >> *** These are timely and important: without them, no new releases of > > >> *anything* are consumed. *** > > >> > > >> https://review.openstack.org/#/c/199353/ is an example. > > >> > > >> They are all in the topic > > >> https://review.openstack.org/#/q/status:open+topic:openstack/requirements/constraints,n,z > > >> > > >> (there is only ever one at a time at the moment, proposed to our > > >> master requirements repo). After liberty branches there may be > > >> multiple ones open - one per release of OpenStack that uses > > >> constraints files. > > >> > > >> I'm putting all this into the documentation too, of course. > > > > > > I'm wondering if we should not refresh them less often. Some of those > > > will trigger some discussion before approval > > > > ^ if they do, its bogus discussion. We never had discussion previously > > when new deps flowed into gate jobs willy-nilly - except when it went > > wrong. The new feature is not a policy knob or control point. Its an > > automated red-green detector for whether those new dep versions would > > have broken devstack (and soon unittests too). Debating the right > > value in upper-constraints.txt is only of relevance to: > > - folk working on resolvers in pip > > - folk dealing with a bad pin that they need to change - and the > > input is *not* upper-constraints.txt, its global-requirements.txt as > > previous. > > > > > , and having them constantly > > > wiped out by new patchsets that add one or two extra bumps is, IMHO, > > > counter-productive... > > > > I'd like to make the job run automatically immediately that we cut a > > release of anything. And I'd also like to get to the point of > > confidence in the whole system that we auto-approve them as soon as > > they go green. > > I think that's appropriate for things we're producing. I'm not sure how > I feel about automatically changing constraints for third-party > packages. Part of the reason for reviewing those was supposed to be to > ensure we're not outstripping what the distros are prepared to ship. Do > we still want to try to keep an eye on that? <SNIP>
I don't think this change is about adding new requirements, just better handling of the current version constraints, which has never been something that has been that tied to distributions, other than attempting to respect DepFreeze[0]. I'm not sure it can be claimed that those reviewing these changes are familiar enough with distributions workflow, and those that are close to distros are probably not as engaged as they could be. That said, I am not sure it matters for this instance. Unless I am mistaken - this is about expanding lower and upper constraints to as wide range as OpenStack projects can support.. which means that distributions can continue (as they currently do) to make sure that their archives fulfil the versions as limited by requirements.txt. This change actually makes it a better experience for them, as they have a more deterministic view of what will work. It doesn't solve the issue of distributions chasing the lowest version, but I am not sure that is an OpenStack problem to solve. Regardless of DepFreeze, I'd expect this effort to be growing the supported external requirements version window rather than causing any surprises. [0] https://wiki.openstack.org/wiki/DepFreeze -- Kind Regards, Dave Walker __________________________________________________________________________ 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
