Open Stack

Excerpts from Robert Collins's message of 2015-07-09 11:17:41 +1200:
> On 9 July 2015 at 11:02, Doug Hellmann <doug at doughellmann.com> wrote:
> > Excerpts from Robert Collins's message of 2015-07-09 07:49:36 +1200:
> >> 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.
> >
> > I think that's appropriate for things we're producing. I'm not sure how
> > I feel about automatically changing constraints for third-party
> > packages. Part of the reason for reviewing those was supposed to be to
> > ensure we're not outstripping what the distros are prepared to ship. Do
> > we still want to try to keep an eye on that?
> 
> That would be a new thing. Until this work was done we reviewed
> changes to *untested minimums*. Since all our test infrastructure ran
> the latest version it could everywhere, it is very common that our
> actual minimum is much lower than our stated minimum. And then we
> raise it when someone notices.
> 
> I'd like to add in a lower-constraints.txt set of pins and actually
> start reporting on whether our lower bounds *work*.
> 
> But what we have now is just more visibility and less breakage with in
> all other regards the same previous behaviour: running the latest
> thing available per global-requirements. If we're going to start
> reviewing 'use new thing only if its packaged', I think we're going to
> have to ask for many more reviewers - we have nearly 300 packages (274
> lines in g-r, 313 in upper-constraints) that change, and making every
> release of any of them require actual thought means we'd need much
> more review bandwidth.
> 
> We could in principle write automation to make our pins honour 'what
> is packaged in RHEL+Fedora+Debian+Ubuntu+Suse' - we could have  a
> database of the versions present in the distros and translate that to
> additional constraints when compiling upper-constraints.txt. So I can
> see a way to automate that. If folk are interested in making that
> happen, I think that it should proceed as follows:
>  - seek consensus that its a needed thing (its not clear that it is to me)
>  - draw up a spec (I'll help)
>  - implement
> 
> Today however, it would be new, and I think we just don't have human
> capacity to do it by hand.

OK. I'll admit I haven't always been looking at updates based on what's
packaged, but we do ask folks who want to add a new package to at least
look into it and report back. I'm OK with us continuing to push forward
with new versions of packages and letting the distros catch up, but I
thought it was worth raising the point explicitly.

Doug