[all][tc] Thoughts on Python 3.7 support
Hello, There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8. Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon: - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237 What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported? Best wishes, Pierre Riteau (priteau)
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with). Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further. -- Jeremy Stanley
On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
This is precisely my expectation: if we support 3.6 and 3.8, it's reasonable to suggest we support 3.7. Not supporting it gains us nothing. Dmitry
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further. -- Jeremy Stanley
-- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Sorry for top posting but just a general remark: Do note Debian 10 is using Python 3.7 and that is what Kolla is testing too. I know Debian is not considered a tested platform but people use it successfully. My opinion is, therefore, that we should keep 3.7 in classifiers. -yoctozepto On Wed, Jan 6, 2021 at 11:37 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
This is precisely my expectation: if we support 3.6 and 3.8, it's reasonable to suggest we support 3.7. Not supporting it gains us nothing.
Dmitry
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further. -- Jeremy Stanley
-- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
+1 I don't see good reasons for removing py3.7 Thanks! On Wed, Jan 6, 2021 at 8:28 AM Radosław Piliszek < radoslaw.piliszek@gmail.com> wrote:
Sorry for top posting but just a general remark:
Do note Debian 10 is using Python 3.7 and that is what Kolla is testing too. I know Debian is not considered a tested platform but people use it successfully.
My opinion is, therefore, that we should keep 3.7 in classifiers.
-yoctozepto
On Wed, Jan 6, 2021 at 11:37 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley <fungi@yuggoth.org>
wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6
and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
This is precisely my expectation: if we support 3.6 and 3.8, it's reasonable to suggest we support 3.7. Not supporting it gains us nothing.
Dmitry
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further. -- Jeremy Stanley
-- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
+1
I don't see good reasons for removing py3.7
On Wed, 2021-01-06 at 09:46 -0300, Victoria Martínez de la Cruz wrote: based on teh agreed testing runtimes for wallaby https://github.com/openstack/governance/blob/master/reference/runtimes/walla... there is no requiremetn for project to maintain testing for py 3.7 but that does not mean the cant elect to test it as an option addtional runtime provided they test teh minium reuiqred vers which are python 3.6 and 3.8 py 3.7 could be maintined as an optional runtime as we do for python 3.9 but i think part of the motivation of droping the 3.7 jobs is to conserve ci bandwith in general and ensure we have enough to test with 3.9 were we can.
Thanks!
On Wed, Jan 6, 2021 at 8:28 AM Radosław Piliszek < radoslaw.piliszek@gmail.com> wrote:
Sorry for top posting but just a general remark:
Do note Debian 10 is using Python 3.7 and that is what Kolla is testing too. I know Debian is not considered a tested platform but people use it successfully.
My opinion is, therefore, that we should keep 3.7 in classifiers.
-yoctozepto
On Wed, Jan 6, 2021 at 11:37 AM Dmitry Tantsur <dtantsur@redhat.com> wrote:
On Tue, Jan 5, 2021 at 10:53 PM Jeremy Stanley <fungi@yuggoth.org>
wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6
and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
This is precisely my expectation: if we support 3.6 and 3.8, it's reasonable to suggest we support 3.7. Not supporting it gains us nothing.
Dmitry
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further. -- Jeremy Stanley
-- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
On 2021-01-06 13:27:28 +0000 (+0000), Sean Mooney wrote: [...]
there is no requiremetn for project to maintain testing for py 3.7 but that does not mean the cant elect to test it as an option addtional runtime provided they test teh minium reuiqred vers which are python 3.6 and 3.8
py 3.7 could be maintined as an optional runtime as we do for python 3.9 but i think part of the motivation of droping the 3.7 jobs is to conserve ci bandwith in general and ensure we have enough to test with 3.9 were we can. [...]
Sure, but that wasn't the question, it was in fact: On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8. [...] Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported? [...]
-- Jeremy Stanley
On 1/6/21 12:26 PM, Radosław Piliszek wrote:
Sorry for top posting but just a general remark:
Do note Debian 10 is using Python 3.7 and that is what Kolla is testing too. I know Debian is not considered a tested platform but people use it successfully.
My opinion is, therefore, that we should keep 3.7 in classifiers.
-yoctozepto
I also confirm that I do run Debian 10 in production with all versions of OpenStack from Rocky to Wallaby, and that I will report if I see anything that doesn't work. I also would like to remind everyone that Bullseye is currently running Python 3.9, and that we should switch the upper bound to at least that... Cheers, Thomas Goirand (zigo)
On 1/5/21 3:51 PM, Jeremy Stanley wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further.
For what little it's worth, that jives with my hazy memories of the discussion too. The assumption was that if we tested the upper and lower bounds of our Python versions then the ones in the middle would be unlikely to break. It was a compromise to support multiple versions of Python without spending a ton of testing resources on it.
---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec <openstack@nemebean.com> wrote ----
On 1/5/21 3:51 PM, Jeremy Stanley wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further.
For what little it's worth, that jives with my hazy memories of the discussion too. The assumption was that if we tested the upper and lower bounds of our Python versions then the ones in the middle would be unlikely to break. It was a compromise to support multiple versions of Python without spending a ton of testing resources on it.
Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing. I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime, we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly it is tested and supported. And testing runtime does not mean we have to drop everything else testing means projects are all welcome to keep running the py3.7 testing job on the gate there is no harm in that. In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers. -gmann
On Wed, 6 Jan 2021 at 18:58, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec <openstack@nemebean.com> wrote ----
On 1/5/21 3:51 PM, Jeremy Stanley wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further.
For what little it's worth, that jives with my hazy memories of the discussion too. The assumption was that if we tested the upper and lower bounds of our Python versions then the ones in the middle would be unlikely to break. It was a compromise to support multiple versions of Python without spending a ton of testing resources on it.
Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing. I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime, we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly it is tested and supported.
And testing runtime does not mean we have to drop everything else testing means projects are all welcome to keep running the py3.7 testing job on the gate there is no harm in that.
In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers.
-gmann
Thanks everyone for your input. Then should we request that those patches dropping the 3.7 classifier are abandoned, or reverted if already merged?
On 1/6/21 3:23 PM, Pierre Riteau wrote:
On Wed, 6 Jan 2021 at 18:58, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec <openstack@nemebean.com> wrote ----
On 1/5/21 3:51 PM, Jeremy Stanley wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further.
For what little it's worth, that jives with my hazy memories of the discussion too. The assumption was that if we tested the upper and lower bounds of our Python versions then the ones in the middle would be unlikely to break. It was a compromise to support multiple versions of Python without spending a ton of testing resources on it.
Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing. I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime, we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly it is tested and supported.
And testing runtime does not mean we have to drop everything else testing means projects are all welcome to keep running the py3.7 testing job on the gate there is no harm in that.
In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers.
-gmann
Thanks everyone for your input. Then should we request that those patches dropping the 3.7 classifier are abandoned, or reverted if already merged?
That would be my takeaway from this discussion, yes.
On Mon, 11 Jan 2021 at 18:09, Ben Nemec <openstack@nemebean.com> wrote:
On 1/6/21 3:23 PM, Pierre Riteau wrote:
On Wed, 6 Jan 2021 at 18:58, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec <openstack@nemebean.com> wrote ----
On 1/5/21 3:51 PM, Jeremy Stanley wrote:
On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon:
- https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237
What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported?
My recollection of the many discussions we held was that the runtime document would recommend the default python3 available in our targeted platforms, but that we would also make a best effort to test with the latest python3 available to us at the start of the cycle as well. It was suggested more than once that we should test all minor versions in between, but this was ruled out based on the additional CI resources it would consume for minimal gain. Instead we deemed that testing our target version and the latest available would give us sufficient confidence that, if those worked, the versions in between them were likely fine as well. Based on that, I think the versions projects claim to work with should be contiguous ranges, not contiguous lists of the exact versions tested (noting that those aren't particularly *exact* versions to begin with).
Apologies for the lack of references to old discussions, I can probably dig some up from the ML and TC meetings several years back of folks think it will help inform this further.
For what little it's worth, that jives with my hazy memories of the discussion too. The assumption was that if we tested the upper and lower bounds of our Python versions then the ones in the middle would be unlikely to break. It was a compromise to support multiple versions of Python without spending a ton of testing resources on it.
Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing. I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime, we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly it is tested and supported.
And testing runtime does not mean we have to drop everything else testing means projects are all welcome to keep running the py3.7 testing job on the gate there is no harm in that.
In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers.
-gmann
Thanks everyone for your input. Then should we request that those patches dropping the 3.7 classifier are abandoned, or reverted if already merged?
That would be my takeaway from this discussion, yes.
I saw that many projects which had merged the "remove py37" patches (e.g. Masakari, Vitrage) have now reverted them, thanks! Skimming through Gerrit, I noticed that Cyborg hasn't merged the revert commits: - https://review.opendev.org/c/openstack/cyborg/+/770719 - https://review.opendev.org/c/openstack/python-cyborgclient/+/770911
participants (9)
-
Ben Nemec
-
Dmitry Tantsur
-
Ghanshyam Mann
-
Jeremy Stanley
-
Pierre Riteau
-
Radosław Piliszek
-
Sean Mooney
-
Thomas Goirand
-
Victoria Martínez de la Cruz