Excerpts from Jeremy Stanley's message of 2018-04-25 21:40:37 +0000:
> On 2018-04-25 16:54:46 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > Still, we need to press on to the next phase of the migration, which
> > I have been calling "Python 3 first". This is where we use python
> > 3 as the default, for everything, and set up the exceptions we need
> > for anything that still requires python 2.
> [...]
> It may be worth considering how this interacts with the switch of
> our default test platform from Ubuntu 16.04 (which provides Python
> 3.5) to 18.04 (which provides Python 3.6). If we switch from 3.5 to
> 3.6 before we change most remaining jobs over to Python 3.x versions
> then it gives us a chance to spot differences between 3.5 and 3.6 at
> that point. Given that the 14.04 to 16.04 migration, where we
> attempted to allow projects to switch at their own pace, didn't go
> so well we're hoping to do a "big bang" migration instead for 18.04
> and expect teams who haven't set up experimental jobs ahead of time
> to work out remaining blockers after the flag day before they can go
> back to business as usual. Since the 18.04 release is happening so
> far into the Rocky cycle, we're likely to want to do that at the
> start of Stein instead when it will be less disruptive.
> So I guess that raises the question: switch to Python 3.5 by default
> for most jobs in Rocky and then have a potentially more disruptive
> default platform switch with Python 3.5->3.6 at the beginning of
> Stein, or wait until the default platform switch to move from Python
> 2.7 to 3.6 as the job default? I can see some value in each option.

Does 18.04 include a python 2 option?

What is the target for completing the changeover? The first or
second milestone for Stein, or the end of the cycle?

It would be useful to have some input from the project teams who
have no unit or functional test jobs running for 3.5, since they
will have the most work to do to cope with the upgrade overall.

Who is coordinating Ubuntu upgrade work and setting up the experimental


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to