Open Stack

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.

> , 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

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud