Excerpts from Robert Collins's message of 2015-07-09 11:07:44 +1200: > On 9 July 2015 at 09:08, Sean Dague <s...@dague.net> 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)
Which job fails if those don't work? Is it a new job, or is it part of one of the existing jobs? Doug > > > 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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev