[openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Doug Hellmann doug at doughellmann.com
Wed Jul 8 23:02:52 UTC 2015


Excerpts from Robert Collins's message of 2015-07-09 07:49:36 +1200:
> On 8 July 2015 at 21:01, Thierry Carrez <thierry at 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?

> 
> > How about we generate those once per week, before Monday starts ? Then
> > we can process them during the week and end up discussing the same
> > thing, rather than a moving target.
> 
> Gosh no. That holds up everyones cycle time to once a week.
> 
> > (We have other things that are refreshed regularly and it's always a
> > race to gather enough approvals before they are regenerated -- I fail to
> > see the benefit of daily refresh vs. weekly refresh here)
> 
> So lets make this a single +A from any core. Its not code review so
> much as 'it looks green and we're not in release-freeze right now'.
> 
> -Rob
> 



More information about the OpenStack-dev mailing list