Open Stack

On Tue, Aug 7, 2018 at 11:28 AM, Zane Bitter <zbitter at redhat.com> wrote:

> Top posting to avoid getting into the weeds.
>
> * OpenStack is indeed lagging behind
> * The road to 3.7 (and eventually 3.8) runs through 3.6
> * As part of the project-wide python3-first goal we aim to have everything
> working on 3.6 for Stein, so we are making some progress at least
> * As of now we are *not* dropping support for 3.5 in Stein
> * No matter what we do, the specific issue you're encountering is
> structural: we don't add support for a Python version in the gate until it
> is available in an Ubuntu LTS release, and that doesn't happen until after
> it is available in Debian, so you will always have the problem that new
> Python versions will be introduced in Debian before we have a gate for them
>

Thanks for mentioning this. I was concerned that there wouldn't be any
gating until Ubuntu 20.04 (April 2020) but Py3.7 is available in bionic
today. It's a bit older version but I think that's just because we're early
py3.7 stages, so we'll try to get that updated.

Thanks,
Corey

* Structural problems require structural solutions; "everybody work
> harder/pay more attention/prioritise differently" will not do it
> * I don't see any evidence that people are refusing to review patches that
> fix 3.7 issues, and I certainly don't think fixing them is 'controversial'
>
>
> On 07/08/18 10:11, Thomas Goirand wrote:
>
>> On 08/07/2018 03:24 PM, Sean Mooney wrote:
>>
>>> so im not sure pushing for python 3.7 is the right thing to do. also i
>>> would not
>>> assume all distros will ship 3.7 in the near term. i have not check
>>> lately but
>>> i believe cento 7 unless make 3.4 and 3.6 available in the default repos.
>>> ubuntu 18.04 ships with 3.6 i believe
>>>
>>
>> The current plan for Debian is that we'll be trying to push for Python
>> 3.7 for Buster, which freezes in January. This freeze date means that
>> it's going to be Rocky that will end up in the next Debian release. If
>> Python 3.7 is a failure, then late November, we will remove Python 3.7
>> from Unstable and let Buster release with 3.6.
>>
>> As for Ubuntu, it is currently unclear if 18.10 will be released with
>> Python 3.7 or not, but I believe they are trying to do that. If not,
>> then 19.04 will for sure be released with Python 3.7.
>>
>> im not sure about other linux distros but since most openstack
>>> deployment are done
>>> on LTS releases of operating systems i would suspect that python 3.6
>>> will be the main
>>> python 3 versions we see deployed in production for some time.
>>>
>>
>> In short: that's wrong.
>>
>> having a 3.7 gate is not a bad idea but priority wise have a 3.6 gate
>>> would be much higher on my list.
>>>
>>
>> Wrong list. One version behind.
>>
>> i think we as a community will have to decide on the minimum and
>>> maximum python 3 versions
>>> we support for each release and adjust as we go forward.
>>>
>>
>> Whatever the OpenStack community decides is not going to change what
>> distributions like Debian will do. This type of reasoning lacks a much
>> needed humility.
>>
>> i would suggst a min of 3.5 and max of 3.6 for rocky.
>>>
>>
>> My suggestion is that these bugs are of very high importance and that
>> they should at least deserve attention. That the gate for Python 3.7
>> isn't ready, I can understand, as everyone's time is limited. This
>> doesn't mean that the OpenStack community at large should just dismiss
>> patches that are important for downstream.
>>
>> for stien perhaps bump that to min of 3.6 max 3.7 but i think this is
>>> something that needs to be address community wide
>>> via a governance resolution rather then per project.
>>>
>>
>> At this point, dropping 3.5 isn't a good idea either, even for Stein.
>>
>> it will also
>>> impact the external python lib we can depend on too which is
>>> another reason i think thie need to be a comuntiy wide discussion and
>>> goal that is informed by what distros are doing but
>>> not mandated by what any one distro is doing.
>>> regards
>>> sean.
>>>
>>
>> Postponing any attempt to support anything current is always a bad idea.
>> I don't see why there's even a controversy when one attempts to fix bugs
>> that will, sooner or later, also hit the gate.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180807/504168a0/attachment.html>