[openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Clark Boylan cboylan at sapwetik.org
Tue Apr 19 16:47:22 UTC 2016

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.


More information about the OpenStack-dev mailing list