Open Stack

On Wed, 2013-02-27 at 16:29 -0500, Sean Dague wrote:
> On 02/27/2013 03:51 PM, Russell Bryant wrote:
> > So I'm not sure that the problems Sean has described here should be
> > considered a disaster.  They seem to be just one of the things our
> > testing should be catching for us.
> 
> I'm not sure I'd call them disaster, but they at least are a calamity.
> 
> > It's not just about getting updates for free.  It's about finding out
> > when our software is no longer compatible with an upstream dependency.
> > It means we found out as soon as we could that there is work to do to
> > update project X to be compatible with new version of dependency Y.  We
> > have to find this out somehow sometime.
> 
> Here's the thing though, because all our software requires all the rest 
> of our software to go through the gate, the current process isn't 
> getting that answer. The pain threshold of a broken merge queue is too 
> high, and the ability to explore removing dependency limitations is too 
> hard.
> 
> I'll use the example from yesterday:
> 
> django 1.5 comes out. Horizon as setup by devstack doesn't do something 
> right by it. The gate stops merging any code. Nova, glance, tempest 
> development is now blocked.

I accept the problem statement - these changes upstream of us shouldn't
break the gate.

We've talked about using the PyPi mirroring infrastructure to solve
this ... we wouldn't allow new versions to be synced into the mirror if
it causes the tests to break.

So, upstream chances would break the PyPI mirror sync and we'd fix that
by pinning and filing a bug to sort out the compat issue. Same end
result (i.e. good data, issue found early) but the gate doesn't get
broken.

> So the answer is pin it as fast as you can because right now horizon is 
> preventing all other projects from doing anything. There really isn't 
> time to figure out the right fix, because you've got 400 contributors 
> sitting on their hands, unable to get anything through CI.
> 
> so we pin, move on. it didn't solve the issue, and the issue got thrown 
> on the back burner because there are bigger fish to fry. Most of the 
> pins in pip-requires showed up because of
> similar issues.

The issue hasn't been fixed, but it has been identified. We now know
that Horizon needs fixing to work with Django 1.5. This is really
important data.

> > Pinning seems like a fine short term fix for this, but only along with a
> > bug for fixing compatibility with this new version of the dependency.
> >
> > I think I could buy pinning everything in stable branches since we
> > wouldn't be doing work in stable branches to chase new versions of
> > dependencies, but not in master.
> 
> I think that for sure we need to pin in stable branches, otherwise it's 
> pretty bad bit rot.

We discussed this at length before:

  http://lists.openstack.org/pipermail/openstack-dev/2012-November/002075.html

and couldn't come to a conclusion about what should into setup.py as our
requires. Pinning is nasty because it artificially limits what versions
of dependencies you can install with.

Cheers,
Mark.