On 11 October 2015 at 01:17, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2015-10-09 18:51:51 +0000 (+0000), Tim Bell wrote: >> There is a need to distinguish between server side py26 support >> which is generally under the control of the service provider and >> py26 support on the client side. For a service provider to push >> all of their hypervisors and service machines to RHEL 7 is under >> their control but requiring all of their users to do the same is >> much more difficult. > [...] > > Agreed, this is why the master branches of clients/libraries opted > to continue testing with Python 2.6 throughout the supported > lifetime of the stable/juno branches. But much like for the service > providers and users, continuing to run older Linux distributions > (CentOS 6.x, Ubuntu 12.4.x) in our test infrastructure comes at a > significant cost and at some point we need to free up our limited > sysadmin resources to focus on better support for more recent distro > releases. > > Once new patches to OpenStack projects are no longer actively tested > on these older platforms, we have to expect that the ability to run > new versions of the projects on them will quickly vanish. However, > users on those older distro releases can opt to continue using > whatever versions last supported them or perhaps fall back on the > versions provided by their distro's package manager.
For pbr I'd actually value keeping 2.6 testing for a bit: because in setup_requires we're not capped anywhere - and those folk that *are* still using 2.6 shouldn't be broken by us - pbr is basically the last thing that can sanely move. I'd be happy with deadsnakes PPA on ubuntu, or a docker container or whatever - just having the confidence that we haven't accidentally broken anything until well past the point that the last release of a higher level library is no longer accepting bug reports - that would be the goal. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
