On 10/18/2015 04:52 PM, Robert Collins wrote:
On 11 October 2015 at 01:17, Jeremy Stanley <[email protected]> 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.
Maybe a non-voting job that adds the deadsnakes PPA and installs 2.6 in
the job setup and then runs pbr tests with it.
I say non-voting because we'd be introducing a direct-internet consuming
test, which increases the risk of failures - but given that the pbr team
is already careful (given the nature of the project) an informational
job should be good enough, no?
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
