Open Stack

On 18-09-05 07:04:12, Andreas Jaeger wrote:
> On 2018-09-05 05:20, Matthew Thode wrote:
> > With the move to per-project requirements (aka divergent requirements)
> > we started allowing projects to have differing exclusions and minimums.
> > As long as projects still tested against upper-constraints we were good.
> > 
> > Part of the reason why we use upper-constraints is to ensure that
> > project A and project B are co-installable.  This is especially useful
> > to distro packagers who can then target upper-constraints for any
> > package updates they need.  Another reason is that we (the requirements
> > team) reviews new global-requirements for code quality, licencing and
> > the like, all of which are useful to Openstack as a whole.
> > 
> > If a projects dependencies are compatible with the global list, and the
> > global list is compatible with the upper-constraints, then the
> > projects' dependencies are compatible with the upper-constraints.
> > 
> > All the above lets us all work together and use any lib listed in
> > global-requirements (at the upper-constraints version).  This is all
> > ensured by having the check-requirements job enabled for your project.
> > It helps ensure co-installability, code quality, python version
> > compatibility, etc.  So please make sure that if you are running
> > everything in your own zuul config (not project-config) that you have
> > the check-requirements job as well.
> 
> 
> And also set up and run the lower-constraints jobs - you can use the new
> template openstack-lower-constraints-jobs for this,
> 

Of course!!!

Lower-constraints are useful (again, mainly for packagers, but also to
know the state of our dependencies).  Specifying and testing
lower-constraints means that there's less potential for bugs that are
caused because a project missed the deprecation of some library feature
that they used.  It also means that we have a second set of constraints
(one that's just for that project) that we know works and can be
targeted if needed.  This massively increases the flexibility of
deployments and packaging.

-- 
Matthew Thode (prometheanfire)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180905/e48547e0/attachment.sig>