Open Stack

On 15 April 2015 at 09:33, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
> On Tue, Apr 14, 2015 at 2:36 AM, Thierry Carrez <thierry at openstack.org>
> wrote:
>>
>> Robert Collins wrote:
>> > On 13 April 2015 at 22:04, Thierry Carrez <thierry at openstack.org> wrote:
>> >> How does this proposal affect stable branches ? In order to keep the
>> >> breakage there under control, we now have stable branches for all the
>> >> OpenStack libraries and cap accordingly[1]. We planned to cap all other
>> >> libraries to "the version that was there when the stable branch was
>> >> cut".  Where would we do those cappings in the new world order ? In
>> >> install_requires ? Or should we not do that anymore ?
>> >>
>> >> [1]
>> >>
>> >> http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html
>> >
>> > I don't think there's a hard and fast answer here. Whats proposed
>> > there should work fine.
>> > [...]
>> >
>> > tl;dr - I dunno :)
>
>
> This is the part of the puzzle I am the most interested in. Making sure
> stable branches don't break out from underneath us forcing us to go into
> fire fighting mode.

I think this is very important too. The spec that James linked to
https://review.openstack.org/#/c/161047/  seems broadly to be heading
in the right direction to me - my -1 on it is because the described
failure mode is very solvable vs e.g. failure modes where dependencies
release broken stuff.

It is in short 'make a fully specified requirements list and use that
via pip -r in stable branch gate jobs'. I think thats entirely sane
(and have been discussing that in various places for a while :)).

*this* thread is about making install_requires, which we currently
source from requirements.txt, be sourced separately (from setup.cfg)
and then we don't need per-repo requirements.txts, which will align us
with the broader ecosystem as far as the definition of
requirements.txt.

We *do* have uses for fully specified things, and one of them is 'what
worked in that test run', which is what the etherpad is intended to
capture.

-Rob


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