On 4/15/19 3:44 PM, Neal Gompa wrote:
On Mon, Apr 15, 2019 at 9:25 AM Michael Ströder <michael@stroeder.com> wrote:
On 4/15/19 2:34 PM, Dominique Leuenberger / DimStar wrote:
But, as a release manager I claim to have a say in this topic too: Dropping py2 is a noble goal, it is a high target. But if this means losing things like firefox, osc, "insertfavoriteapphere" - then you all can be sure that we will weigh the pros and cons of keeping/dropping py2. In plus, with a capable maintainer who is willing to further work on possibly reported CVEs: how can we claim it is not maintained?!
So, please, let's tone this thread down a notch: Maej formulated a goal to remove python2 by 2020 - and as a distribution I hope we can all see the benefit of not having to maintain something that is abandoned upstream. But just jumping off the cliff because upstream declares something unmaintained is not going to happen.
Let me describe my personal situation:
1. I'm supporting Linux distros like CentOS7 where the standard distro does not ship with Python3 yet. So there is some constraint there.
Python 3.6 is coming to the base EL7 distribution with the 7.7 release: https://bugzilla.redhat.com/show_bug.cgi?id=1639030
Prior to this, Python 3 has been available through Software Collections in both EL6 and EL7.
Python 3 is also available in EPEL for EL6 and EL7.
Extra repos cannot be always used in every environment. I'm pretty sure you know such installations.
So I don't consider this as a valid excuse, as there are ways to have a usable Python 3 environment.
This is not meant as general "excuse" to not work on the migration. It's an explanation that I have to keep things running in the mean-time.
2. I do want to migrate to Python3. But when touching all the code I'd like make sure to really move to Python3 (especially with type hints). So I won't maintain modules compatible to both 2 and 3 to avoid all the ugly code mess you can find in various module packages.
But with a Python maintainer moving stuff around, breaking existing config workflows I'm forced to implement many work-arounds wasting my time. I'd really prefer to spend this time on migrating the upstream code base!
Use a Tumbleweed snapshot for that. It's an effective strategy if you consider Factory churn to hurt your development process. But frankly, when I worked on getting Pagure to Python 3, I worked from Tumbleweed almost exclusively. It worked out well, even with the churn, because I could keep validating against new stuff.
Be assured I know how to use Tumbleweed - not only for development. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org