Open Stack

On 2016-04-21 14:05:17 +1200 (+1200), Robert Collins wrote:
> On 20 April 2016 at 03:00, Jeremy Stanley <fungi at yuggoth.org> wrote:
[...]
> > 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 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).
[...]

Yep, that's what I was trying to convey above. We still need to
resolve upper-constraints.txt from something, and there was debate
as to whether it would be effective to generate it from the
unversioned requirements list in global/requirements or whether we
would need to resolve it from an aggregation of the still-versioned
requirements files in participating projects. Also briefly touched
on was the option of possibly dropping version specifiers from
individual project requirements files.

> Atomic multi-branch commits in zuul would allow us to fix
> multi-project wedging issues if constraints are federated out to
> multiple trees.
[...]

This still runs counter to the desire to serialize changes proposed
on different branches for the purpose of confirming upgrades from
one branch to another aren't broken by one change and then quietly
fixed by another.
-- 
Jeremy Stanley