On 9 July 2015 at 09:08, Sean Dague <[email protected]> wrote: > So I think the issue is that we used to have a manual process (reviewing > g-r adds), and some automated stuff that happens after that. > > Now we seem to have a manual process, that triggers some automatic > stuff, and requires another manual piece before it all works, then > automatic bits happen. > > That seems to just add a lot more error proneness to this. Instead can > we make this pip resolve process part of the automated testing so that > it just fails if upper-constraints is incorrect on the g-r proposal?
It already is to a reasonable approximation. Specifically: - we make sure the new g-r can be compiled successfully (see tools/integration.sh). - we make sure the new upper-constraints.txt and g-r are mutually compatible (see openstack_requirements/tests/test_integration.py) > I guess I'm missing the part where that has to be done as a second job > submission instead of at the same time as the g-r proposal. I think people *should* generate it locally and include it. We can't fix-it-for them (because we can't change the commit in CI, it has to come in well formed). We can't require that CI finds the *same result* because noone would ever be able to land anything - the landscape moves too fast for our review latency. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
