As I'm sure you are aware, OpenStack has done its last Python 2.6 compatible release, and the test infrastructure is being unwound rapidly.
We've one special case in the projects we manage - pbr - and I'm trying to see if there is going to be enough impact that we need to special case it for CI and keep Python 2.6 as a supported version for now. tl;dr: If you are still building OpenStack packages with Python 2.6, and depending on pbr being installed via easy-install, please read the rest of the mail and reply. If I get no replies, or the respondents won't be deeply affected, then we'll go into 'best effort' mode where we don't CI on 2.6, and just act reactively to reported issues - e.g. its not that we won't *care*, its just that we'll be reacting rather than preventing. Details: Most of our projects easily cappable to deal with Python 2.6 incompatibilities, but pbr, as a setup_requires dependency, is not: setup_requires is handled by easy-install, and since the majority of our pbr references are not capped (for good reasons that are irrelevant here), this means that if pbr breaks compatibility with Python 2.6, *and* folk are installing pbr using projects on Python 2.6, then easy-install will pick the latest, 2.6 incompatible version, and break builds. This can be mitigated by pre-installing pbr with 2.6 compatible version; OTOH thats not always easy when things are at the bottom of deep tooling chains. So the questions are: a) Are you still deploying on 2.6 b) and if so do you depend on easy-install at any stage [that is, do you not already pre-install pbr everywhere yourself] c) and if so will it be hard/disruptive for you to pre-install pbr ? -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
