Open Stack

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

>> , and having them constantly
>> wiped out by new patchsets that add one or two extra bumps is, IMHO,
>> counter-productive...
> 
> I'd like to make the job run automatically immediately that we cut a
> release of anything. And I'd also like to get to the point of
> confidence in the whole system that we auto-approve them as soon as
> they go green.
> 
>> How about we generate those once per week, before Monday starts ? Then
>> we can process them during the week and end up discussing the same
>> thing, rather than a moving target.
> 
> Gosh no. That holds up everyones cycle time to once a week.
> 
>> (We have other things that are refreshed regularly and it's always a
>> race to gather enough approvals before they are regenerated -- I fail to
>> see the benefit of daily refresh vs. weekly refresh here)
> 
> So lets make this a single +A from any core. Its not code review so
> much as 'it looks green and we're not in release-freeze right now'.
> 
> -Rob
>