[gentoo-python] [RFC] Timeline for Python 3.6 adoption

[Michał Górny]

Hi, everyone.

I think we've reached the point where we should start discussing
switching the defaults to Python 3.6. I would like to gather your
opinion the following ideas.

Firstly, I'd like to do two changes simultaneously to reduce --newuse
rebuilds:

a. switching from CPython 3.5 to 3.6,

b. disabling CPython 3.4.

I'm thinking of a soft deadline on 2018-06-01, i.e. giving developers
a full month to prepare. If things don't go well, we can always
postpone it.

According to my lists, we only have 6 packages relying on py3.4 right
now [1] and no pending stabilizations for that. I will report bugs for
those packages today.

The list for 3.5->3.6 migration is longer [2]. However, it seems that
many of those packages are rather isolated [3] and apparently
unmaintained. Apparently the biggest targets are OpenStack
and Flask. It's all doable.

What do you think?

[1]:https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
[2]:https://qa-reports.gentoo.org/output/gpyutils/35-to-36.txt
[3]:https://qa-reports.gentoo.org/output/gpyutils/35-to-36.svg

[Mike Gilbert]

Post by Michał Górny
Hi, everyone.
I think we've reached the point where we should start discussing
switching the defaults to Python 3.6. I would like to gather your
opinion the following ideas.
Firstly, I'd like to do two changes simultaneously to reduce --newuse
a. switching from CPython 3.5 to 3.6,
b. disabling CPython 3.4.
I'm thinking of a soft deadline on 2018-06-01, i.e. giving developers
a full month to prepare. If things don't go well, we can always
postpone it.
According to my lists, we only have 6 packages relying on py3.4 right
now [1] and no pending stabilizations for that. I will report bugs for
those packages today.
The list for 3.5->3.6 migration is longer [2]. However, it seems that
many of those packages are rather isolated [3] and apparently
unmaintained. Apparently the biggest targets are OpenStack
and Flask. It's all doable.
What do you think?

...

June 1 seems a little optimistic to me, but as you said we can push it
out if needed.

This plan makes sense to me.

[Patrick McLean]

Post by Mike Gilbert

Post by Michał Górny
Firstly, I'd like to do two changes simultaneously to reduce --newuse
a. switching from CPython 3.5 to 3.6,
b. disabling CPython 3.4.

I assume you mean remove from the default PYTHON_TARGETS, not disable it
completely? I would wait until after python 3.4 is no longer getting
updates before removing it from the eclass and the tree.

Post by Mike Gilbert

Post by Michał Górny
I'm thinking of a soft deadline on 2018-06-01, i.e. giving developers
a full month to prepare. If things don't go well, we can always
postpone it.
According to my lists, we only have 6 packages relying on py3.4 right
now [1] and no pending stabilizations for that. I will report bugs for
those packages today.
The list for 3.5->3.6 migration is longer [2]. However, it seems that
many of those packages are rather isolated [3] and apparently
unmaintained. Apparently the biggest targets are OpenStack
and Flask. It's all doable.
What do you think?

June 1 seems a little optimistic to me, but as you said we can push it
out if needed.
This plan makes sense to me.

...

[Michał Górny]

W dniu pią, 27.04.2018 o godzinie 17∶56 -0700, użytkownik Patrick McLean

Post by Patrick McLean

Post by Mike Gilbert

Post by Michał Górny
Firstly, I'd like to do two changes simultaneously to reduce --newuse
a. switching from CPython 3.5 to 3.6,
b. disabling CPython 3.4.

I assume you mean remove from the default PYTHON_TARGETS, not disable it
completely? I would wait until after python 3.4 is no longer getting
updates before removing it from the eclass and the tree.

I meant disabling it completely. The default is 3.5 for a long time
already, and there is no reason to expect people to go back and test
their packages against 3.4. The plan was to support only one Python 3.x
release behind current stable.

Post by Patrick McLean

Post by Mike Gilbert

Post by Michał Górny
I'm thinking of a soft deadline on 2018-06-01, i.e. giving developers
a full month to prepare. If things don't go well, we can always
postpone it.
According to my lists, we only have 6 packages relying on py3.4 right
now [1] and no pending stabilizations for that. I will report bugs for
those packages today.
The list for 3.5->3.6 migration is longer [2]. However, it seems that
many of those packages are rather isolated [3] and apparently
unmaintained. Apparently the biggest targets are OpenStack
and Flask. It's all doable.
What do you think?

June 1 seems a little optimistic to me, but as you said we can push it
out if needed.
This plan makes sense to me.

...

[Patrick McLean]

Post by Mike Gilbert

Post by Michał Górny
Firstly, I'd like to do two changes simultaneously to reduce --newuse
a. switching from CPython 3.5 to 3.6,
b. disabling CPython 3.4.

I assume you mean remove from the default PYTHON_TARGETS, not disable it
completely? I would wait until after python 3.4 is no longer getting
updates before removing it from the eclass and the tree.

Post by Mike Gilbert

Post by Michał Górny
I'm thinking of a soft deadline on 2018-06-01, i.e. giving developers
a full month to prepare. If things don't go well, we can always
postpone it.
According to my lists, we only have 6 packages relying on py3.4 right
now [1] and no pending stabilizations for that. I will report bugs for
those packages today.
The list for 3.5->3.6 migration is longer [2]. However, it seems that
many of those packages are rather isolated [3] and apparently
unmaintained. Apparently the biggest targets are OpenStack
and Flask. It's all doable.
What do you think?

June 1 seems a little optimistic to me, but as you said we can push it
out if needed.
This plan makes sense to me.

...