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

Robert Collins robertc at robertcollins.net
Thu Apr 21 02:05:17 UTC 2016

On 20 April 2016 at 03:00, Jeremy Stanley <fungi at yuggoth.org> wrote:
> 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 think I suggested that we could remove the *versions* from
global-requirements. Constraints being in a single place is a
necessary tool unless (we have atomic-multi-branch commits via zuul ||
we never depend on two projects agreeing on compatible versions of
libraries in the CI jobs that run for any given project).

Constraints being in a single place (not necessarily a single file)
allows to fix multi-project wedging issues with a single git commit.
Atomic multi-branch commits in zuul would allow us to fix
multi-project wedging issues if constraints are federated out to
multiple trees.
Never needing any two projects to agree on compatible versions in CI
would allow us to change things without triggering a wedge...
possibly. *detailed* thought needed here - because consider for
instance the impact of a removed release on PyPI.


Robert Collins <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud

More information about the OpenStack-dev mailing list