Open Stack

Excerpts from Robert Collins's message of 2015-07-09 11:07:44 +1200:
> On 9 July 2015 at 09:08, Sean Dague <sean at 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
>