Open Stack

On Wed, 6 Jan 2021 at 18:58, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>
>  ---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec <openstack at 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?