On 5 January 2014 02:02, Sean Dague <s...@dague.net> wrote: > So we used to do that the apps against release libraries. And the result was > more and more full day gate breaks. We did 2 consecutive ones in 2 weeks. > > Basically, once you get to be a certain level of coupled in OpenStack we can > no longer let you manage your own requirements file. We need a global lever > on it. Because people were doing it wrong, and slowly (we could go through > specific examples about how bad this was. This was a top issue at nearly > every summit I'd been at going back to Essex. >.. > (It was about 14 days to resolve the python client issue, there was a django > issue around the same time that never made it to the list, as we did it all > under fire in IRC) > > And we have a solution now. Which is one list of requirements that we can > test everything with, that we can propose requirements updates > speculatively, and see what works and what doesn't. And *after* we know they > work, we propose the changes back into the projects, now automatically.
So the flip-flop thing is certainly very interesting. We wouldn't want that to happen again. >> I do see the issue Sean is pointing at, which is that we have to fix >> the libraries first and then the things that use them. OTOH thats >> normal in the software world, I don't see anything unique about it. > > > Well, as the person that normally gets stuck figuring this out when .eu has > been gate blocked for a day, and I'm one of the first people up on the east > coast, I find the normal state of affairs unsatisfying. :) :) > I also think that what we are basically dealing with is the classical N^2 > comms problem. With N git trees that we need to all get working together, > this gets exponentially more difficult over time. Which is why we created > the integrated gate and the global requirements lever. I don't think we are - I think we're dealing with the fact that we've had no signal - no backpressure - on projects that have upper caps set to remove those caps. So they stick there and we all suffer. > Another solution would be reduce the number of OpenStack git trees to make > N^2 more manageable, and let us with single commits affect multiple > components. But that's not the direction we've taken. I don't think thats necessary. What I'd like to see is: A) two test sets for every commit: - commit with latest-release of all deps - commit with latest-trunk [or dependent zuul ref] of all deps B) *if* there are upper version caps for any reason, some signal back to developers that this exists and that we need to fix our code to work with that newer release. - Possibly we should allow major version caps where major releases are anticipated to be incompatible without warning about that *until* there is a [pre-]release of the new major version available -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev