Open Stack

On 07/08/2015 07:07 PM, Robert Collins wrote:
> 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)
> 
>> 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.

Maybe, I'm not convinced though. This should be just like config file
samples, yes you need to stay on top of them, especially as libraries
release, but it should be fine. Reviewers can also regen pretty easily
to get things to pass tests. I do merge conflict resolution like this
quite often as part of the review.

Part of review latency is about understandability of reviews inbound.
And I think this double review bit is just going to make it worse.

	-Sean

-- 
Sean Dague
http://dague.net