Open Stack

Sean Dague wrote:
> As we're dealing with the fact that testtools 1.4.0 apparently broke
> something with attribute additions to tests (needed by tempest for
> filtering), it raises an interesting problem.
> 
> Our current policy on requirements is to leave them open ended, this
> lets us take upstream fixes. It also breaks us a lot. But our max
> version of dependencies happens with 0 code review or testing.
> 
> However, fixing these things takes a bunch of debug, code review, and
> test time. Seen by the fact that the testtools 1.2.0 block didn't even
> manage to fully merge this weekend.
> 
> This is an asymetric break/fix path, which I think we need a better plan
> for. If fixing is more expensive than breaking, then you'll tend to be
> in a broken state quite a bit. We really actually want the other
> asymetry if we can get it.

+1

> There are a couple of things we could try here:
> 
> == Cap all requirements, require code reviews to bump maximums ==
> 
> Benefits, protected from upstream breaks.
> 
> Down sides, requires active energy to move forward. The SQLA 0.8
> transition took forever.

I think all projects which do manual dep bumps just end up not keeping
up with the state of the world over time. It's just too much pain to
bump them, introduce risk for so little gain for the party involved (you
just created an externality). You would only bump stuff when you need a
new feature/fix from a new version of the library, which would (1) make
those bumps more costly for the poor soul that will end up needing the
new version and (2) go stale on everything else, not getting free
bugfixes from library authors and generally making the distributions
lives more miserable.

This is totally doable (and desirable imho) on stable branches though,
and we plan to just do that there.

> == Provide Requirements core push authority ==
> 
> For blocks on bad versions, if we had a fast path to just merge know
> breaks, we could right ourselves quicker. It would have reasonably
> strict rules, like could only be used to block individual versions.
> Probably that should also come with sending email to the dev list any
> time such a thing happened.
> 
> Benefits, fast to fix
> 
> Down sides, bypasses our testing infrastructure. Though realistically
> the break bypassed it as well.

That doesn't sound completely crazy. Currently we give the upstream
projects the ability to directly break us, without giving our own
requirements-core the ability to directly fix the breakage.

-- 
Thierry Carrez (ttx)