On 12/16/2015 02:22 PM, Andrey Kurilin wrote: >>If it had py26 classifiers, that was an error. > > The list of libraries with py26 classifiers is too huge: > astara - stable/kilo, stable/liberty > astara-appliance - stable/kilo, stable/liberty > astara-horizon - stable/kilo, stable/liberty > astara-neutron - stable/kilo, stable/liberty > bifrost - stable/liberty > ceilometermiddleware - stable/kilo, stable/liberty > cloudkitty-dashboard - stable/kilo > compute-hyperv - stable/kilo, stable/liberty > congress - stable/kilo, stable/liberty > debtcollector - stable/kilo, stable/liberty > designate - stable/kilo, stable/liberty > designate-dashboard - stable/liberty > glance_store - stable/kilo > group-based-policy - stable/kilo > group-based-policy-automation - stable/kilo > group-based-policy-ui - stable/kilo > instack-undercloud - stable/liberty > keystoneauth - stable/liberty > keystonemiddleware - stable/kilo > magnum - stable/kilo, stable/liberty > magnum-ui - stable/liberty > manila-ui - stable/kilo, stable/liberty > mox3 - stable/liberty > networking-bagpipe - stable/kilo, stable/liberty > networking-bgpvpn - stable/kilo, stable/liberty > networking-hyperv - stable/kilo, stable/liberty > networking-infoblox - stable/liberty > networking-l2gw - stable/kilo, stable/liberty > networking-nec - stable/kilo > networking-ovs-dpdk - stable/kilo, stable/liberty > networking-plumgrid - stable/kilo, stable/liberty > networking-vsphere - stable/kilo, stable/liberty > nova-docker - stable/kilo, stable/liberty > nova-solver-scheduler - stable/kilo > os-brick - stable/liberty > os-client-config - stable/liberty > oslo-incubator - stable/kilo > oslo.cache - stable/liberty > oslo.concurrency - stable/kilo, stable/liberty > oslo.config - stable/kilo, stable/liberty > oslo.context - stable/kilo, stable/liberty > oslo.db - stable/kilo, stable/liberty > oslo.i18n - stable/kilo, stable/liberty > oslo.log - stable/kilo, stable/liberty > oslo.messaging - stable/kilo > oslo.middleware - stable/kilo, stable/liberty > oslo.policy - stable/kilo, stable/liberty > oslo.reports - stable/liberty > oslo.rootwrap - stable/kilo, stable/liberty > oslo.serialization - stable/kilo, stable/liberty > oslo.service - stable/liberty > oslo.utils - stable/kilo, stable/liberty > oslo.versionedobjects - stable/kilo > oslo.vmware - stable/kilo, stable/liberty > oslosphinx - stable/kilo, stable/liberty > oslotest - stable/kilo, stable/liberty > pycadf - stable/kilo, stable/liberty > python-barbicanclient - stable/kilo, stable/liberty > python-ceilometerclient - stable/kilo, stable/liberty > python-cinderclient - stable/kilo, stable/liberty > python-congressclient - stable/kilo, stable/liberty > python-designateclient - stable/kilo, stable/liberty > python-glanceclient - stable/kilo, stable/liberty > python-group-based-policy-client - stable/kilo > python-heatclient - stable/kilo, stable/liberty > python-ironicclient - stable/kilo, stable/liberty > python-keystoneclient - stable/kilo, stable/liberty > python-magnumclient - stable/kilo, stable/liberty > python-neutronclient - stable/kilo, stable/liberty > python-novaclient - stable/kilo, stable/liberty > python-openstackclient - stable/kilo, stable/liberty > python-saharaclient - stable/kilo, stable/liberty > python-swiftclient - stable/kilo, stable/liberty > python-tackerclient - stable/kilo, stable/liberty > python-troveclient - stable/kilo, stable/liberty > python-zaqarclient - stable/kilo, stable/liberty > requirements - stable/kilo, stable/liberty > stevedore - stable/liberty > swift - stable/kilo > tacker - stable/kilo, stable/liberty > tacker-horizon - stable/kilo, stable/liberty > taskflow - stable/kilo > tooz - stable/kilo > tripleo-common - stable/liberty > yaql - stable/kilo, stable/liberty > zaqar - stable/kilo, stable/liberty
Andrey, I don't think it is reasonable to use these classifiers to say we are declaring support Py2.6. Those classifier, despite their high numbers, are just wrong. It is very annoying that you've found out how widely spread the false declaration is. Maybe it is time that we collectively take a better care of it. It has been discussed in this list for a long time that we wouldn't support Python 2.6 after Juno. Right now, it is unfortunately a way too late to go back on this decision. There's anyway nobody that is volunteering to do the work on the infra side. I am well aware that this is causing problems for MOS and Fuel, with our master node still running on CentOS 6 for Fuel/MOS 6 and 7. IMO, we should have switch to CentOS 7 a year ago, not now, but it is too late to regret. The only thing we can do here, is doing patches as we see issues rising. I don't believe this kind of patch would be strongly refused if they pass the Python 2.7 gates. If they are, then I will strongly oppose to the refusal of such patch. Worst case, we can maintain our own private Python 2.6 patches for the remaining time when we need Python 2.6 in Kilo and Liberty. Let's learn from this mistake, and have Fuel / MOS sync faster with the rest of OpenStack, so that we don't have this kind of issue again in the future. Feel free to propose patches to remove these Py2.6 classifiers. Maybe the best approach for it would be having the proposal bot to do such patches. Cheers, Thomas Goirand (zigo) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
