Re: [openstack-dev] [all][python3][tc][infra] Python 3.6
On Tue, Jun 05, 2018 at 04:48:00PM -0400, Zane Bitter wrote: > On 05/06/18 16:38, Doug Hellmann wrote: > > Excerpts from Zane Bitter's message of 2018-06-05 15:55:49 -0400: > > > We've talked a bit about migrating to Python 3, but (unless I missed it) > > > not a lot about which version of Python 3. Currently all projects that > > > support Python 3 are gating against 3.5. However, Ubuntu Artful and > > > Fedora 26 already ship Python 3.6 by default. (And Bionic and F28 have > > > been released since then.) The one time it did come up in a thread, we > > > decided it was blocked on the availability of 3.6 in Ubuntu to run on > > > the test nodes, so it's time to discuss it again. > > > > > > AIUI we're planning to switch the test nodes to Bionic, since it's the > > > latest LTS release, so I'd assume that means that when we talk about > > > running docs jobs, pep8 &c. with Python3 (under the python3-first > > > project-wide goal) that means 3.6. And while 3.5 jobs should continue to > > > work, it seems like we ought to start testing ASAP with the version that > > > users are going to get by default if they choose to use our Python3 > > > packages. > > > > > > The list of breaking changes in 3.6 is quite short (although not zero), > > > so I wouldn't expect too many roadblocks: > > > https://docs.python.org/3/whatsnew/3.6.html#porting-to-python-3-6 > > > > > > I think we can split the problem into two parts: > > > > > > * How can we detect any issues ASAP. > > > > > > Would it be sane to give all projects with a py35 unit tests job a > > > non-voting py36 job so that they can start fixing any issues right away? > > > Like this: https://review.openstack.org/572535 > > > > That seems like a good way to start. > > > > Maybe we want to rename that project template to openstack-python3-jobs > > to keep it version-agnostic? > > You mean the 35_36 one? Actually, let's discuss this on the review. > Yes please lets keep python35 / python36 project-templates, I've left comments in review. > > > > > > * How can we ensure every project fixes any issues and migrates to > > > voting gates, including for functional test jobs? > > > > > > Would it make sense to make this part of the 'python3-first' > > > project-wide goal? > > > > Yes, that seems like a good idea. We can be specific about the version > > of python 3 to be used to achieve that goal (assuming it is selected as > > a goal). > > > > The instructions I've been putting together are based on just using > > "python3" in the tox.ini file because I didn't want to have to update > > that every time we update to a new version of python. Do you think we > > should be more specific there, too? > > That's probably fine IMHO. We should just be aware that e.g. when distros > start switching to 3.7 then people's local jobs will start running in 3.7. > > For me, at least, this has already been the case with 3.6 - tox is now > python3 by default in Fedora, so e.g. pep8 jobs have been running under 3.6 > for a while now. There were a *lot* of deprecation warnings at first. > > > Doug > > > > > > > > cheers, > > > Zane. > > > > > > > > > (Disclaimer for the conspiracy-minded: you might assume that I'm > > > cleverly concealing inside knowledge of which version of Python 3 will > > > replace Python 2 in the next major release of RHEL/CentOS, but in fact > > > you would be mistaken. The truth is I've been too lazy to find out, so > > > I'm as much in the dark as anybody. Really. Anyway, this isn't about > > > that, it's about testing within upstream OpenStack.) > > > > > > > __ > > 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 > > > > > __ > 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 __ 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
Re: [openstack-dev] [all][python3][tc][infra] Python 3.6
On 06/05/2018 02:55 PM, Zane Bitter wrote: [snip] The list of breaking changes in 3.6 is quite short (although not zero), so I wouldn't expect too many roadblocks: https://docs.python.org/3/whatsnew/3.6.html#porting-to-python-3-6 I think we can split the problem into two parts: * How can we detect any issues ASAP. Would it be sane to give all projects with a py35 unit tests job a non-voting py36 job so that they can start fixing any issues right away? Like this: https://review.openstack.org/572535 FWIW, Cinder has had py36 jobs running (and voting) for both unit tests and functional tests for just over a month now with no issues - https://review.openstack.org/#/c/564513/ * How can we ensure every project fixes any issues and migrates to voting gates, including for functional test jobs? Would it make sense to make this part of the 'python3-first' project-wide goal? +1 cheers, Zane. __ 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
Re: [openstack-dev] [all][python3][tc][infra] Python 3.6
On 05/06/18 16:38, Doug Hellmann wrote: Excerpts from Zane Bitter's message of 2018-06-05 15:55:49 -0400: We've talked a bit about migrating to Python 3, but (unless I missed it) not a lot about which version of Python 3. Currently all projects that support Python 3 are gating against 3.5. However, Ubuntu Artful and Fedora 26 already ship Python 3.6 by default. (And Bionic and F28 have been released since then.) The one time it did come up in a thread, we decided it was blocked on the availability of 3.6 in Ubuntu to run on the test nodes, so it's time to discuss it again. AIUI we're planning to switch the test nodes to Bionic, since it's the latest LTS release, so I'd assume that means that when we talk about running docs jobs, pep8 &c. with Python3 (under the python3-first project-wide goal) that means 3.6. And while 3.5 jobs should continue to work, it seems like we ought to start testing ASAP with the version that users are going to get by default if they choose to use our Python3 packages. The list of breaking changes in 3.6 is quite short (although not zero), so I wouldn't expect too many roadblocks: https://docs.python.org/3/whatsnew/3.6.html#porting-to-python-3-6 I think we can split the problem into two parts: * How can we detect any issues ASAP. Would it be sane to give all projects with a py35 unit tests job a non-voting py36 job so that they can start fixing any issues right away? Like this: https://review.openstack.org/572535 That seems like a good way to start. Maybe we want to rename that project template to openstack-python3-jobs to keep it version-agnostic? You mean the 35_36 one? Actually, let's discuss this on the review. * How can we ensure every project fixes any issues and migrates to voting gates, including for functional test jobs? Would it make sense to make this part of the 'python3-first' project-wide goal? Yes, that seems like a good idea. We can be specific about the version of python 3 to be used to achieve that goal (assuming it is selected as a goal). The instructions I've been putting together are based on just using "python3" in the tox.ini file because I didn't want to have to update that every time we update to a new version of python. Do you think we should be more specific there, too? That's probably fine IMHO. We should just be aware that e.g. when distros start switching to 3.7 then people's local jobs will start running in 3.7. For me, at least, this has already been the case with 3.6 - tox is now python3 by default in Fedora, so e.g. pep8 jobs have been running under 3.6 for a while now. There were a *lot* of deprecation warnings at first. Doug cheers, Zane. (Disclaimer for the conspiracy-minded: you might assume that I'm cleverly concealing inside knowledge of which version of Python 3 will replace Python 2 in the next major release of RHEL/CentOS, but in fact you would be mistaken. The truth is I've been too lazy to find out, so I'm as much in the dark as anybody. Really. Anyway, this isn't about that, it's about testing within upstream OpenStack.) __ 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 __ 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
Re: [openstack-dev] [all][python3][tc][infra] Python 3.6
Excerpts from Zane Bitter's message of 2018-06-05 15:55:49 -0400: > We've talked a bit about migrating to Python 3, but (unless I missed it) > not a lot about which version of Python 3. Currently all projects that > support Python 3 are gating against 3.5. However, Ubuntu Artful and > Fedora 26 already ship Python 3.6 by default. (And Bionic and F28 have > been released since then.) The one time it did come up in a thread, we > decided it was blocked on the availability of 3.6 in Ubuntu to run on > the test nodes, so it's time to discuss it again. > > AIUI we're planning to switch the test nodes to Bionic, since it's the > latest LTS release, so I'd assume that means that when we talk about > running docs jobs, pep8 &c. with Python3 (under the python3-first > project-wide goal) that means 3.6. And while 3.5 jobs should continue to > work, it seems like we ought to start testing ASAP with the version that > users are going to get by default if they choose to use our Python3 > packages. > > The list of breaking changes in 3.6 is quite short (although not zero), > so I wouldn't expect too many roadblocks: > https://docs.python.org/3/whatsnew/3.6.html#porting-to-python-3-6 > > I think we can split the problem into two parts: > > * How can we detect any issues ASAP. > > Would it be sane to give all projects with a py35 unit tests job a > non-voting py36 job so that they can start fixing any issues right away? > Like this: https://review.openstack.org/572535 That seems like a good way to start. Maybe we want to rename that project template to openstack-python3-jobs to keep it version-agnostic? > > * How can we ensure every project fixes any issues and migrates to > voting gates, including for functional test jobs? > > Would it make sense to make this part of the 'python3-first' > project-wide goal? Yes, that seems like a good idea. We can be specific about the version of python 3 to be used to achieve that goal (assuming it is selected as a goal). The instructions I've been putting together are based on just using "python3" in the tox.ini file because I didn't want to have to update that every time we update to a new version of python. Do you think we should be more specific there, too? Doug > > cheers, > Zane. > > > (Disclaimer for the conspiracy-minded: you might assume that I'm > cleverly concealing inside knowledge of which version of Python 3 will > replace Python 2 in the next major release of RHEL/CentOS, but in fact > you would be mistaken. The truth is I've been too lazy to find out, so > I'm as much in the dark as anybody. Really. Anyway, this isn't about > that, it's about testing within upstream OpenStack.) > __ 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
Re: [openstack-dev] [all][python3][tc][infra] Python 3.6
On 2018-06-05 15:55:49 -0400 (-0400), Zane Bitter wrote: [...] > AIUI we're planning to switch the test nodes to Bionic, since it's > the latest LTS release, so I'd assume that means that when we talk > about running docs jobs, pep8 &c. with Python3 (under the > python3-first project-wide goal) that means 3.6. And while 3.5 > jobs should continue to work, it seems like we ought to start > testing ASAP with the version that users are going to get by > default if they choose to use our Python3 packages. [...] Yes, though to clarify it's sanest to interpret our LTS distro statement as testing on whatever the latest LTS release is at the _start_ of the development cycle. Switching default testing platforms has proven to be extremely disruptive to the development process so we want that to happen as soon after the coordinated release as feasible. That means the plan is to have the mandatory PTI jobs for the Rocky cycle stick with Ubuntu 16.04 LTS (our ubuntu-xenial nodes) which provides Python 3.5, but encourage teams to add jobs running on Ubuntu 18.04 LTS (our ubuntu-bionic nodes) as soon as they can to get a leg up on any potential disruption (including the Python 3.6 it provides) before we force the PTI jobs over to it at the start of the Stein cycle. -- Jeremy Stanley signature.asc Description: PGP signature __ 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
[openstack-dev] [all][python3][tc][infra] Python 3.6
We've talked a bit about migrating to Python 3, but (unless I missed it) not a lot about which version of Python 3. Currently all projects that support Python 3 are gating against 3.5. However, Ubuntu Artful and Fedora 26 already ship Python 3.6 by default. (And Bionic and F28 have been released since then.) The one time it did come up in a thread, we decided it was blocked on the availability of 3.6 in Ubuntu to run on the test nodes, so it's time to discuss it again. AIUI we're planning to switch the test nodes to Bionic, since it's the latest LTS release, so I'd assume that means that when we talk about running docs jobs, pep8 &c. with Python3 (under the python3-first project-wide goal) that means 3.6. And while 3.5 jobs should continue to work, it seems like we ought to start testing ASAP with the version that users are going to get by default if they choose to use our Python3 packages. The list of breaking changes in 3.6 is quite short (although not zero), so I wouldn't expect too many roadblocks: https://docs.python.org/3/whatsnew/3.6.html#porting-to-python-3-6 I think we can split the problem into two parts: * How can we detect any issues ASAP. Would it be sane to give all projects with a py35 unit tests job a non-voting py36 job so that they can start fixing any issues right away? Like this: https://review.openstack.org/572535 * How can we ensure every project fixes any issues and migrates to voting gates, including for functional test jobs? Would it make sense to make this part of the 'python3-first' project-wide goal? cheers, Zane. (Disclaimer for the conspiracy-minded: you might assume that I'm cleverly concealing inside knowledge of which version of Python 3 will replace Python 2 in the next major release of RHEL/CentOS, but in fact you would be mistaken. The truth is I've been too lazy to find out, so I'm as much in the dark as anybody. Really. Anyway, this isn't about that, it's about testing within upstream OpenStack.) __ 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
