Open Stack

On 07/08/2015 04:21 PM, Monty Taylor wrote:
> On 07/08/2015 03:49 PM, Robert Collins wrote:
>> On 8 July 2015 at 21:01, Thierry Carrez <thierry at openstack.org> wrote:
>>> Robert Collins wrote:
>>>> We've finally gotten all the kinks worked out and now
>>>> upper-constraints proposals should be coming in daily.
>>>>
>>>> *** These are timely and important: without them, no new releases of
>>>> *anything* are consumed. ***
>>>>
>>>> https://review.openstack.org/#/c/199353/ is an example.
>>>>
>>>> They are all in the topic
>>>> https://review.openstack.org/#/q/status:open+topic:openstack/requirements/constraints,n,z
>>>>
>>>> (there is only ever one at a time at the moment, proposed to our
>>>> master requirements repo). After liberty branches there may be
>>>> multiple ones open - one per release of OpenStack that uses
>>>> constraints files.
>>>>
>>>> I'm putting all this into the documentation too, of course.
>>>
>>> I'm wondering if we should not refresh them less often. Some of those
>>> will trigger some discussion before approval
>>
>> ^ if they do, its bogus discussion. We never had discussion previously
>> when new deps flowed into gate jobs willy-nilly - except when it went
>> wrong. The new feature is not a policy knob or control point. Its an
>> automated red-green detector for whether those new dep versions would
>> have broken devstack (and soon unittests too). Debating the right
>> value in upper-constraints.txt is only of relevance to:
>>  - folk working on resolvers in pip
>>  - folk dealing with a bad pin that they need to change - and the
>> input is *not* upper-constraints.txt, its global-requirements.txt as
>> previous.
> 
> I agree 100% with lifeless

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?

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.

	-Sean

-- 
Sean Dague
http://dague.net