Discussion:
Intent to orphan Python 2
(too old to reply)
Petr Viktorin
2018-03-23 11:23:17 UTC
Permalink
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.


Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.

Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2
alive, we won't be the ones doing it – at least not at the current
magnitude".
Here are the details.


The current maintainers of python2 would like to "orphan" the python2
package in 2020 (~ Fedora 30):
- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)

As with any orphaning, that leaves two options:
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
- dependent packages drop support for Python 2.

Unlike most other orphanings, we have some thousands of dependent
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested
packagers, as long as there's an understanding that we won't just
support python2 forever.

If you are a maintainer of anything at [1] we ask you kindly to consider
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora >
29. (On the current schedule, Fedora 30 will be the first release still
supported after 2020-01-01.)

If no one steps up to maintain python2 after 2020, we're prepared to
package a "legacy" python27 package, similar to what we do for e.g.
python33 [2], to:
- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if
their upstreams don't manage to port to Python 3 in time



[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-
Matěj Cepl
2018-03-23 13:29:32 UTC
Permalink
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of
January, 2020, after almost 10 years (!) of volunteer
maintenance.
Just a note of warning: don’t to be too over-eager with dropping
everything Python 2 related in EPEL-7. Its EOS is only sometime
after 2024
(https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle)
and the question whether the packages which can use both Python2
and Python3 as its dependency (e.g., youtube-dl) should switch
to Python3 or use the base RHEL-provided Python 2.7.

Best,

Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: ***@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

It is a rare mind indeed that can render the hitherto
non-existent blindingly obvious. The cry “I could have thought of
that” is a very popular and misleading one, for the fact is that
they didn’t, and a very significant and revealing fact it is too.
-- Douglas Adams, Dirk Gently's Holistic Detective Agency
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email t
Jerry James
2018-03-23 14:16:39 UTC
Permalink
Post by Matěj Cepl
Just a note of warning: don’t to be too over-eager with dropping
everything Python 2 related in EPEL-7. Its EOS is only sometime
after 2024
(https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle)
and the question whether the packages which can use both Python2
and Python3 as its dependency (e.g., youtube-dl) should switch
to Python3 or use the base RHEL-provided Python 2.7.
And please don't start dropping python 2 subpackages that are actually
used by other packages in Fedora without talking to the maintainers
first. I just got bitten by this change to python-nose-cov:

* Thu Mar 22 2018 John Dulaney <***@fedoraproject.org> - 1.6-13 -
Drop python2 subpackage

And now koschei is sending me emails about how all of my packages that
use python-nose-cov have broken dependencies in Rawhide. I'm not
ready to drop python2 support for those packages yet; they are
dependencies of still other packages. We need to start this process
from the leaves and work back towards the roots, not the other way
around.

For each of these, I can of course simply run %check for the python3
subpackage, and skip the python2 subpackage, but then breakages to the
python2 subpackage might go unnoticed.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Miro Hrončok
2018-03-23 16:18:02 UTC
Permalink
Post by Jerry James
And please don't start dropping python 2 subpackages that are actually
used by other packages in Fedora without talking to the maintainers
Drop python2 subpackage
And now koschei is sending me emails about how all of my packages that
use python-nose-cov have broken dependencies in Rawhide. I'm not
ready to drop python2 support for those packages yet; they are
dependencies of still other packages. We need to start this process
from the leaves and work back towards the roots, not the other way
around.
Exactly. You can check if your package is a leaf at [1].

[1] http://fedora.portingdb.xyz/#legacy-leaf
Post by Jerry James
For each of these, I can of course simply run %check for the python3
subpackage, and skip the python2 subpackage, but then breakages to the
python2 subpackage might go unnoticed.
Please don't do hacks. Non-leaf packages should not be removed (at least
not without prior talk to your dependent packages maintainers). If a
maintainer removes a non-leaf package, please report to them that they
break things (like you just did, thank you).

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to dev
Ralf Corsepius
2018-03-23 15:07:51 UTC
Permalink
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
Bummer - I am speechless.
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
Correct.

Face it, your plan is naive and has failed even before it begun.


Ralf
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leave
Randy Barlow
2018-03-23 16:03:33 UTC
Permalink
Post by Ralf Corsepius
Face it, your plan is naive and has failed even before it begun.
This is not useful feedback, and is hostile. Please use only
constructive criticism in the future.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an em
Richard W.M. Jones
2018-03-24 15:09:46 UTC
Permalink
Post by Ralf Corsepius
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we
need to start dropping python2 packages now.
Bummer - I am speechless.
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of January,
2020, after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 –
many more than we can support without upstream help.
Correct.
Face it, your plan is naive and has failed even before it begun.
As well as being rude, I think you're wrong on a technical level, and
that's a shame because I generally respect your (often contrarian)
viewpoint on this list.

I see a number of problems with Python 2:

- Packaging two versions of Python is painful. See for example the
hoops we have to go through both upstream & downstream for hivex
(as one example, others include: virt-v2v, libguestfs, virt-* tools).

- Python 2 also has a bunch of serious deficiencies dealing with
UTF-8 strings which are largely fixed in 3.

I'm not personally a fan of either variant of the language - it's
silly that we let programmers use an unsafe, slow, interpreted
scripting language when we've known how to make better programming
environments for at least 40 years.

But it's hard to argue with a plan which has been pre-announced
*2 years* in advance. If only all Fedora changes were given such a
generous runway.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to dev
Matěj Cepl
2018-03-24 19:56:02 UTC
Permalink
Post by Richard W.M. Jones
I'm not personally a fan of either variant of the language
- it's silly that we let programmers use an unsafe, slow, interpreted
scripting language when we've known how to make better programming
environments for at least 40 years.
Just curious: better programming environments … such us?

Best,

Matěj
--
https://matej.ceplovi.cz/blog/, Jabber: ***@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8

One reason that life is complex is that it has a real part and an
imaginary part.
-- Andrew König
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an ema
Richard W.M. Jones
2018-03-24 23:12:31 UTC
Permalink
Post by Matěj Cepl
Post by Richard W.M. Jones
I'm not personally a fan of either variant of the language
- it's silly that we let programmers use an unsafe, slow, interpreted
scripting language when we've known how to make better programming
environments for at least 40 years.
Just curious: better programming environments … such us?
Anything in the ML family of course.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.
Silvia Sánchez
2018-03-25 07:44:52 UTC
Permalink
Hi everyone,

First, I agree with Richard that packaging two versions is painful. It's
also confusing from the other side. "Install Python. I already have it.
No, that's Python2, you need Python3. (O_O)"
Second, I think the earlier we start the better. So there's time to cut
leafs and replace old libraries in Python2 with equivalents in Python3,
dropping packages, etc. By the time, Python2 is definitely deprecated,
most of the work is done and only some details remain.
Third, upgrading packages and changing dependencies is no minor tasks. With
time, it can be done silently with testing enough so there are no major
issues.
Side question, what is ML?

Kind regards,
Silvia
FAS:Lailah
Post by Richard W.M. Jones
Post by Richard W.M. Jones
I'm not personally a fan of either variant of the language
- it's silly that we let programmers use an unsafe, slow, interpreted
scripting language when we've known how to make better programming
environments for at least 40 years.
Just curious: better programming environments 
 such us?
Anything in the ML family of course.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~
rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
_______________________________________________
Kevin Kofler
2018-03-25 12:25:36 UTC
Permalink
Post by Silvia Sánchez
First, I agree with Richard that packaging two versions is painful. It's
also confusing from the other side. "Install Python. I already have it.
No, that's Python2, you need Python3. (O_O)"
The packages are already renamed or being renamed to python2*, and the plan
is also to switch the Provides so that python3 will be the package Providing
python, not python2. That should solve that issue without having to nuke
python2.
Post by Silvia Sánchez
Second, I think the earlier we start the better. So there's time to cut
leafs and replace old libraries in Python2 with equivalents in Python3,
dropping packages, etc. By the time, Python2 is definitely deprecated,
most of the work is done and only some details remain.
I am strongly opposed to removing working software that is still useful for
users. There is certainly very useful niche software that has not been
ported to Python 3 yet.

I am all for kicking out Python 2 from things such as live images if it is
still on them, for space reasons. But I think it needs to remain available
in the repository.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an
Miro Hrončok
2018-03-25 14:21:35 UTC
Permalink
Post by Kevin Kofler
I am all for kicking out Python 2 from things such as live images if it is
still on them, for space reasons. But I think it needs to remain available
in the repository.
And we are not saying "python2 needs to get out", we are saying
"somebody needs to take care of it, we are stepping down (or it needs to
get out if nobody is willing to do that)".

We are also saying "think about your python2-foo packages, do you
consider them still useful? if not, nuke them at will, but our
recommendation is Fedora 29 or 30"

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorapro
stan
2018-03-25 16:59:01 UTC
Permalink
On Sat, 24 Mar 2018 23:12:31 +0000
Post by Matěj Cepl
Just curious: better programming environments … such us?
Anything in the ML family of course.
So, in looking it up, those languages have been around for almost 50
years, and they haven't "caught on". Why? Programmers are usually
quick to pick up something which is better. What is it about ML family
languages that have caused them to be passed over?

I tried programming in lisp a long time ago, and found it was not a
good fit for the way I think about programming solutions because of its
functional nature. Is that the reason for most people? To put it
another way, if people don't cut their teeth on declarative languages,
if their first exposure to programming is via a functional language, do
they then embrace functional programming? Or is it like right and left
handedness, inherent in people, with the majority preferring
declarative?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorapro
Randy Barlow
2018-03-23 16:57:19 UTC
Permalink
Post by Petr Viktorin
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
I'm +1 to the idea of dropping Python 2 support in general, but I'm not
sure we should really do it gradually (which is what would effectively
happen if some packagers start dropping now and others later, and others
not at all). It seems to me like it'd be cleaner to have a release note
on Fedora 30 that's just "Python 2 support dropped" and do it all at
once. Thoughts?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leav
Gerald Henriksen
2018-03-23 21:53:52 UTC
Permalink
Post by Randy Barlow
Post by Petr Viktorin
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
I'm +1 to the idea of dropping Python 2 support in general, but I'm not
sure we should really do it gradually (which is what would effectively
happen if some packagers start dropping now and others later, and others
not at all). It seems to me like it'd be cleaner to have a release note
on Fedora 30 that's just "Python 2 support dropped" and do it all at
once. Thoughts?
It's not just all the Python 2 code that is packaged in Fedora though,
but also all the Python 2 code people are running on their machines.

By gradually (or sooner than Fedora 30) getting rid of all the
libraries and other Python 2 stuff it at least gives the option for
those people who get surprised to fix things before the Python
interpreter itself goes EOL and doesn't get security fixes.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to
Kevin Kofler
2018-03-24 14:28:47 UTC
Permalink
Post by Petr Viktorin
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
IMHO, this is clearly the right thing to do. I have been doing security
backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs 4.
It is not an unreasonable amount of work, though to be very clear I will NOT
be the one to do this for Python 2, somebody experienced with and interested
in Python should do it.

Especially for the first couple years, it will be possible to just borrow
fixes from other distros, in particular RHEL/CentOS. As was pointed out
elsewhere in this thread, EL7 ships Python 2.7 and should be supported until
2024. (That said, RHEL typically only fixes the really critical issues. My
experience with qt3 and kdelibs3 is that RHEL was not always proactive in
backporting security fixes and sometimes even ended up picking up my Fedora
fix, weeks later. But there are also other distros around.)

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedora
Petr Viktorin
2018-03-26 09:58:57 UTC
Permalink
Post by Kevin Kofler
Post by Petr Viktorin
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
IMHO, this is clearly the right thing to do. I have been doing security
backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs 4.
It is not an unreasonable amount of work, though to be very clear I will NOT
be the one to do this for Python 2, somebody experienced with and interested
in Python should do it.
And if you read the original mail to the end, you'll find that our
position is not as black-and-white as it might look from the Subject line.
As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* –
but just for developers who need to test backwards compatibility of
their upstream libraries; we don't want to see them used as a base for
Fedora packages. Why? To make sure Fedora packages work with modern
Python, and to have only one time-sensitive place to concentrate on when
a critical security fix comes. We want to put Python 2.7 in the same
situation.

Part of the reason to start dropping Python 2 packages now is to figure
out which packages can do it now and which ones will need additional
help or coordination in the next few years.

As I wrote in the beginning of the e-mail, we'd rather go out and change
the packaging guidelines to say "please drop your unneeded python2
subpackages, or let us drop them for you". (Note the word *unneeded*.)
That would make a nice a simple message, and in effect it would give you
the same options you have now.
But it turns out we can't say just that (for good reasons [0]), so we're
explicitly mentioning your second option – "if you can manage the
transition better, come and do it instead of us".
I doubt anyone can – Python SIG is, by definition, the people
experienced with and interested in packaging Python in Fedora. And yes,
we'll do our best to manage things, with cooperation with interested
packagers.

There's of course a third option – if you don't want to take over
*everything* but have ideas about how to do something better –
respecting that if you're asking someone to do more work, they might (or
might not) say no – then come over to Python SIG [1] and talk!

And let me mention this one explicitly: expecting us to maintain Python
2 *is* implicitly asking us to do work. It's not necessarily bad per se,
but don't complain if we ask you to do some work in return.
We'll be glad to help anyone who respects that.


[0] https://pagure.io/packaging-committee/issue/753
[1] https://fedoraproject.org/wiki/SIGs/Python
Post by Kevin Kofler
Especially for the first couple years, it will be possible to just borrow
fixes from other distros, in particular RHEL/CentOS. As was pointed out
elsewhere in this thread, EL7 ships Python 2.7 and should be supported until
2024. (That said, RHEL typically only fixes the really critical issues. My
experience with qt3 and kdelibs3 is that RHEL was not always proactive in
backporting security fixes and sometimes even ended up picking up my Fedora
fix, weeks later. But there are also other distros around.)
Kevin Kofler
_______________________________________________
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an em
James Hogarth
2018-04-04 16:21:32 UTC
Permalink
Post by Petr Viktorin
Post by Kevin Kofler
Post by Petr Viktorin
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
IMHO, this is clearly the right thing to do. I have been doing security
backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs
4.
Post by Kevin Kofler
It is not an unreasonable amount of work, though to be very clear I will
NOT
Post by Kevin Kofler
be the one to do this for Python 2, somebody experienced with and
interested
Post by Kevin Kofler
in Python should do it.
And if you read the original mail to the end, you'll find that our
position is not as black-and-white as it might look from the Subject line.
As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* –
but just for developers who need to test backwards compatibility of
their upstream libraries; we don't want to see them used as a base for
Fedora packages. Why? To make sure Fedora packages work with modern
Python, and to have only one time-sensitive place to concentrate on when
a critical security fix comes. We want to put Python 2.7 in the same
situation.
Part of the reason to start dropping Python 2 packages now is to figure
out which packages can do it now and which ones will need additional
help or coordination in the next few years.
As I wrote in the beginning of the e-mail, we'd rather go out and change
the packaging guidelines to say "please drop your unneeded python2
subpackages, or let us drop them for you". (Note the word *unneeded*.)
That would make a nice a simple message, and in effect it would give you
the same options you have now.
But it turns out we can't say just that (for good reasons [0]), so we're
explicitly mentioning your second option – "if you can manage the
transition better, come and do it instead of us".
I doubt anyone can – Python SIG is, by definition, the people
experienced with and interested in packaging Python in Fedora. And yes,
we'll do our best to manage things, with cooperation with interested
packagers.
There's of course a third option – if you don't want to take over
*everything* but have ideas about how to do something better –
respecting that if you're asking someone to do more work, they might (or
might not) say no – then come over to Python SIG [1] and talk!
And let me mention this one explicitly: expecting us to maintain Python
2 *is* implicitly asking us to do work. It's not necessarily bad per se,
but don't complain if we ask you to do some work in return.
We'll be glad to help anyone who respects that.
[0] https://pagure.io/packaging-committee/issue/753
[1] https://fedoraproject.org/wiki/SIGs/Python
Post by Kevin Kofler
Especially for the first couple years, it will be possible to just borrow
fixes from other distros, in particular RHEL/CentOS. As was pointed out
elsewhere in this thread, EL7 ships Python 2.7 and should be supported
until
Post by Kevin Kofler
2024. (That said, RHEL typically only fixes the really critical issues.
My
Post by Kevin Kofler
experience with qt3 and kdelibs3 is that RHEL was not always proactive in
backporting security fixes and sometimes even ended up picking up my
Fedora
Post by Kevin Kofler
fix, weeks later. But there are also other distros around.)
Kevin Kofler
_______________________________________________
_______________________________________________
Can we please get some consistency here?

I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of
course we ship firewalld as our firewall in fedora.

This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.

Worse is if you bump into a module not ported yet and then you have a split
of python versions and playbooks required.

Naturally there's no technical reason to drop the library in F28 and
there's no Change filed for it.

We at least need a "common bugs" with all the python2-* libraries being
dropped in F28 and really they shouldn't be going without a Change.

For a "soft despondency" like firewalld I'd argue that it shouldn't drop
until F29 when ansible goes py3 by default (it has a Change filed to that
effect).

To be clear I'm 100% comfortable with python2 being dropped in the proposed
timescale... but let's do it sensibly and not have it surprise people.
Kevin Fenzi
2018-04-04 17:46:28 UTC
Permalink
On 04/04/2018 09:21 AM, James Hogarth wrote:

...snip...
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of
course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost,
which you could add to your command line with -e...
-e 'ansible_python_interpreter=/usr/bin/python3'
Post by James Hogarth
Worse is if you bump into a module not ported yet and then you have a split
of python versions and playbooks required.
Yeah, thats bad, but if there's things that are only python2 as of now,
really the ansible module/you should switch them to some python3
alternative.
Post by James Hogarth
Naturally there's no technical reason to drop the library in F28 and
there's no Change filed for it.
Yeah, I guess the only alternative though would be to try dropping them
all at once. :(
Post by James Hogarth
We at least need a "common bugs" with all the python2-* libraries being
dropped in F28 and really they shouldn't be going without a Change.
For a "soft despondency" like firewalld I'd argue that it shouldn't drop
until F29 when ansible goes py3 by default (it has a Change filed to that
effect).
Well, yes, but that doesn't really tell the entire story, because thats
just the control host. You can continue to use python2 on targets.
Post by James Hogarth
To be clear I'm 100% comfortable with python2 being dropped in the proposed
timescale... but let's do it sensibly and not have it surprise people.
Yeah, a list/release note would be indeed welcome...

kevin

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai
Kevin Fenzi
2018-04-04 17:51:43 UTC
Permalink
Post by Kevin Fenzi
...snip...
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of
course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost,
which you could add to your command line with -e...
-e 'ansible_python_interpreter=/usr/bin/python3'
Or, actually:

yum install ansible-python3 python-firewall
ansible localhost -m firewalld

(since ansible-python3 defaults to python3 for the control host/localhost)

kevin
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai
Adam Williamson
2018-04-04 20:27:49 UTC
Permalink
Post by Kevin Fenzi
Post by Kevin Fenzi
...snip...
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of
course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost,
which you could add to your command line with -e...
-e 'ansible_python_interpreter=/usr/bin/python3'
yum install ansible-python3 python-firewall
ansible localhost -m firewalld
(since ansible-python3 defaults to python3 for the control host/localhost)
This rather begs the question of whether there are any modules which
only work *with python 2*, though...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedora
James Hogarth
2018-04-04 20:35:56 UTC
Permalink
Post by Petr Viktorin
Post by Kevin Fenzi
Post by Kevin Fenzi
...snip...
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of
course
Post by Kevin Fenzi
Post by Kevin Fenzi
Post by James Hogarth
ansible isn't switching to py3 for the controller (and therefore
local)
Post by Kevin Fenzi
Post by Kevin Fenzi
Post by James Hogarth
until F29 and not all python modules are py3 compatible yet... and of
course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it
work.
Post by Kevin Fenzi
Post by Kevin Fenzi
Yeah, you would need to set ansible_python_interpreter for localhost,
which you could add to your command line with -e...
-e 'ansible_python_interpreter=/usr/bin/python3'
yum install ansible-python3 python-firewall
ansible localhost -m firewalld
(since ansible-python3 defaults to python3 for the control
host/localhost)
This rather begs the question of whether there are any modules which
only work *with python 2*, though...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
The ansible guys might know... or might not really tbh which is why the
current documentation upstream still declares it a technology preview.

The test coverage is growing there but not massively comprehensive... and
tbh I expect the greater problem will be random galaxy stuff or local
plugins and modules people have written.

It's going to be a very disruptive change in F29 as it is... to the extent
I might start directing people to use the upstream ansible repos directly
if they don't change there.

I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm
looking at with intense trepidation.
Kevin Fenzi
2018-04-04 21:06:48 UTC
Permalink
Post by James Hogarth
Post by Adam Williamson
This rather begs the question of whether there are any modules which
only work *with python 2*, though...
The answer is (at least based on what I know from talking with upstream)
that ansible has been pretty well tested with python3 for the controller
host. All upstream PR's are tested against both python2 and python3. All
upstream CI runs against python2 and python3.

For the target/managed node side: all core modules have been tested
under python3. Community supported modules however they have been fixing
python3 issues as they come up. There's not any full testing thats
happened over all those, nor is there likely to be.

Heres the list of known python3 bugs in modules:
https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Apython3+label%3Abug
Post by James Hogarth
The ansible guys might know... or might not really tbh which is why the
current documentation upstream still declares it a technology preview.
The test coverage is growing there but not massively comprehensive... and
tbh I expect the greater problem will be random galaxy stuff or local
plugins and modules people have written.
Right.

However, they do say that most problems are trivial to fix up also.
Post by James Hogarth
It's going to be a very disruptive change in F29 as it is... to the extent
I might start directing people to use the upstream ansible repos directly
if they don't change there.>
I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm
looking at with intense trepidation.
Well, if it happens... some people might choose to keep it alive.

kevin
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe sen
James Hogarth
2018-04-04 23:27:07 UTC
Permalink
Post by Kevin Fenzi
Post by James Hogarth
Post by Adam Williamson
This rather begs the question of whether there are any modules which
only work *with python 2*, though...
The answer is (at least based on what I know from talking with upstream)
that ansible has been pretty well tested with python3 for the controller
host. All upstream PR's are tested against both python2 and python3. All
upstream CI runs against python2 and python3.
For the target/managed node side: all core modules have been tested
under python3. Community supported modules however they have been fixing
python3 issues as they come up. There's not any full testing thats
happened over all those, nor is there likely to be.
https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Apython3+label%3Abug
Yup this is why I'm very nervous about the F29/F30 plans in the face of this ...
Post by Kevin Fenzi
Post by James Hogarth
The ansible guys might know... or might not really tbh which is why the
current documentation upstream still declares it a technology preview.
The test coverage is growing there but not massively comprehensive... and
tbh I expect the greater problem will be random galaxy stuff or local
plugins and modules people have written.
Right.
However, they do say that most problems are trivial to fix up also.
Trivial ... but still need time and people to review, merge and then
release them.

Stuff in galaxy can be fixed relatively quickly by owners as it
bypasses github stuff of course ... but modules shipped with ansible
already will take a while to go from PR to a built and shipped
release.
Post by Kevin Fenzi
Post by James Hogarth
It's going to be a very disruptive change in F29 as it is... to the extent
I might start directing people to use the upstream ansible repos directly
if they don't change there.>
I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm
looking at with intense trepidation.
Well, if it happens... some people might choose to keep it alive.
kevin
_______________________________________________
Well ... even if they do that doesn't help if a bunch of packages
(especially pretty core ones to Fedora like firewalld) drop their
python2 libraries ...
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to dev
Bill Nottingham
2018-04-04 20:58:30 UTC
Permalink
Post by Adam Williamson
This rather begs the question of whether there are any modules which
only work *with python 2*, though...
Given 1500+ modules, all of which can have their own python library
dependencies, the safe answer is 'yes'.

We're working to solve that, but it's a proces...

Bill
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send
James Hogarth
2018-04-04 20:31:41 UTC
Permalink
Post by Kevin Fenzi
Post by Kevin Fenzi
...snip...
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of
course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Yeah, you would need to set ansible_python_interpreter for localhost,
which you could add to your command line with -e...
-e 'ansible_python_interpreter=/usr/bin/python3'
yum install ansible-python3 python-firewall
ansible localhost -m firewalld
(since ansible-python3 defaults to python3 for the control host/localhost)
kevin
_______________________________________________
You're right that solves the issue for the control host, assuming
everything else you are doing on there is fine with py3, but doesn't solve
F28 target systems.

It is also unexpected and not in and changes notes or common issues (yet)
...


What happens to systems that currently have the library during an upgrade?

It was just dropped from the spec (As many will be) rather than formally
retired so it's not added to the "this is dead" super obsoleting package.

Even if we don't get a change per library (which I agree would be too much)
can we please get something clear for the F28 (and later F29) release ...
we should be able to quickly generate it with dnf list
Petr Viktorin
2018-04-06 09:18:13 UTC
Permalink
On 04/04/18 18:21, James Hogarth wrote:
[...]
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of
course we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum  install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a
split of python versions and playbooks required.
Is there some list of packages Ansible depends on?
I'd can to add the list to portingdb, so we could warn people about the
implications of dropping subpackages. Currently we use RPM deps, so the
needs of Ansible clients are invisible.
Post by James Hogarth
Naturally there's no technical reason to drop the library in F28 and
there's no Change filed for it.
It's the maintainer's decision, as with any RPM.
Has anyone communicated to the firewalld maintainer that Ansible depends
on the package? Again, a maintainer can't very well notice a "soft
dependency", unless they use Ansible themselves.
Post by James Hogarth
We at least need a "common bugs" with all the python2-* libraries being
dropped in F28 and really they shouldn't be going without a Change.
Post by James Hogarth
For a "soft despondency" like firewalld I'd argue that it shouldn't drop
until F29 when ansible goes py3 by default (it has a Change filed to
that effect).
To be clear I'm 100% comfortable with python2 being dropped in the
proposed timescale... but let's do it sensibly and not have it surprise
people.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.f
James Hogarth
2018-04-06 10:09:10 UTC
Permalink
Post by Petr Viktorin
[...]
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of course
we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a
split of python versions and playbooks required.
Is there some list of packages Ansible depends on?
I'd can to add the list to portingdb, so we could warn people about the
implications of dropping subpackages. Currently we use RPM deps, so the
needs of Ansible clients are invisible.
It's not even as simple as that ... as Bill Nottingham mentioned the
bigger problem is going to the be the thousands of libraries and
plugins on eg ansible galaxy out there ...

It's just going to be a huge (but required, just we need to be careful
on communication so as not to tarnish our image ... especially with a
core Red Hat technology like ansible) disruption.
Post by Petr Viktorin
Post by James Hogarth
Naturally there's no technical reason to drop the library in F28 and
there's no Change filed for it.
It's the maintainer's decision, as with any RPM.
Has anyone communicated to the firewalld maintainer that Ansible depends on
the package? Again, a maintainer can't very well notice a "soft dependency",
unless they use Ansible themselves.
Right ... but that's why we have the Change process - so stuff like
this can get noticed in good time and those who are aware of soft
dependencies can speak up.

There's a good reason we have the change deadlines we do - and
honestly I think dropping a subpackage (as opposed to retiring which
is more visible) is sufficiently disruptive (and annoyingly invisible
otherwise) that it should go through the Change process.

It's also bigger than firewalld - that's just the one that bit me the
other day when trying to do owncloud testing.

Do note that, despite my dislike for dropping the subpackage without
an announced Change, the biggest issue I see here is the sheer lack of
communication with out userbase with what is going on.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to dev
Charalampos Stratakis
2018-04-06 10:28:44 UTC
Permalink
----- Original Message -----
Sent: Friday, April 6, 2018 12:09:10 PM
Subject: Re: Intent to orphan Python 2
Post by Petr Viktorin
[...]
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of course
ansible isn't switching to py3 for the controller (and therefore local)
until F29 and not all python modules are py3 compatible yet... and of course
we ship firewalld as our firewall in fedora.
This means that in F28 you can't just `yum install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you have a
split of python versions and playbooks required.
Is there some list of packages Ansible depends on?
I'd can to add the list to portingdb, so we could warn people about the
implications of dropping subpackages. Currently we use RPM deps, so the
needs of Ansible clients are invisible.
It's not even as simple as that ... as Bill Nottingham mentioned the
bigger problem is going to the be the thousands of libraries and
plugins on eg ansible galaxy out there ...
It's just going to be a huge (but required, just we need to be careful
on communication so as not to tarnish our image ... especially with a
core Red Hat technology like ansible) disruption.
Post by Petr Viktorin
Post by James Hogarth
Naturally there's no technical reason to drop the library in F28 and
there's no Change filed for it.
It's the maintainer's decision, as with any RPM.
Has anyone communicated to the firewalld maintainer that Ansible depends on
the package? Again, a maintainer can't very well notice a "soft dependency",
unless they use Ansible themselves.
Right ... but that's why we have the Change process - so stuff like
this can get noticed in good time and those who are aware of soft
dependencies can speak up.
AFAIK there is no guideline for making the packagers responsible for
soft dependencies, or anything guiding how to check for those.

If anything, the people who care about that should draft something
to avoid those nuisances.

Again if someone sees their package as leaves within the distribution,
how could he be aware of anything requiring it outside the rpm level? At this
point I don't think anyone would even think of the change process for packages
that on the surface nothing depends on.
There's a good reason we have the change deadlines we do - and
honestly I think dropping a subpackage (as opposed to retiring which
is more visible) is sufficiently disruptive (and annoyingly invisible
otherwise) that it should go through the Change process.
It's also bigger than firewalld - that's just the one that bit me the
other day when trying to do owncloud testing.
Do note that, despite my dislike for dropping the subpackage without
an announced Change, the biggest issue I see here is the sheer lack of
communication with out userbase with what is going on.
_______________________________________________
--
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.o
Adam Williamson
2018-04-07 16:47:48 UTC
Permalink
Post by James Hogarth
There's a good reason we have the change deadlines we do - and
honestly I think dropping a subpackage (as opposed to retiring which
is more visible) is sufficiently disruptive (and annoyingly invisible
otherwise) that it should go through the Change process.
It wouldn't be remotely viable to have a Change for every dropped
subpackage. It'd completely overwhelm the process.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-le
Zbigniew Jędrzejewski-Szmek
2018-04-07 13:43:12 UTC
Permalink
Post by Petr Viktorin
[...]
Post by James Hogarth
Can we please get some consistency here?
I noted today that firewalld has dropped python2-firewall but of
course ansible isn't switching to py3 for the controller (and
therefore local) until F29 and not all python modules are py3
compatible yet... and of course we ship firewalld as our firewall
in fedora.
This means that in F28 you can't just `yum  install ansible
python-firewall` and do ansible localhost -m firewalld and have it work.
Worse is if you bump into a module not ported yet and then you
have a split of python versions and playbooks required.
Is there some list of packages Ansible depends on?
I'd can to add the list to portingdb, so we could warn people about
the implications of dropping subpackages. Currently we use RPM deps,
so the needs of Ansible clients are invisible.
Post by James Hogarth
Naturally there's no technical reason to drop the library in F28
and there's no Change filed for it.
It's the maintainer's decision, as with any RPM.
Has anyone communicated to the firewalld maintainer that Ansible
depends on the package? Again, a maintainer can't very well notice a
"soft dependency", unless they use Ansible themselves.
I think it's just something that a maintainer should know —
how users actually use the package they are maintaining.
Removing a python subpackage should be handled similarly to any other
removal, for example of an executable or certain functionality from an
executable. Get a rough idea of what will be impacted, and reach out
to users about the change.

https://codesearch.debian.net/search?q=import+firewall
immediately gives a list of packages that should be checked.
I don't have an inkling where python-firewall would be used, but
for packages that I maintain, I have at least a general idea, and
then it's much easier to search.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fe
Kevin Fenzi
2018-04-07 20:14:29 UTC
Permalink
Post by Petr Viktorin
Is there some list of packages Ansible depends on?
Nope. I don't think there could be either.
(Or at least not a very good one).

You could possibly scrape the core modules shipped with ansible, but
thats going to give you tons of things that aren't even in Fedora or are
free software, and we cannot know what custom modules many people have
written or what they depend on.

kevin
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai
Matthew Miller
2018-04-05 12:23:22 UTC
Permalink
Post by Petr Viktorin
And if you read the original mail to the end, you'll find that our
position is not as black-and-white as it might look from the Subject line.
As Python SIG we maintain old Python versions like 2.6 or 3.3
*today* – but just for developers who need to test backwards
compatibility of their upstream libraries; we don't want to see them
used as a base for Fedora packages. Why? To make sure Fedora
packages work with modern Python, and to have only one
time-sensitive place to concentrate on when a critical security fix
comes. We want to put Python 2.7 in the same situation.
Sorry I'm a late to this thread. Have you considered making the
"legacy" python 2.7 a module? This would provide a clear way to define
the lifecycle and service level expectations.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedo
James Hogarth
2018-04-05 14:11:47 UTC
Permalink
Post by Matthew Miller
Post by Petr Viktorin
And if you read the original mail to the end, you'll find that our
position is not as black-and-white as it might look from the Subject line.
As Python SIG we maintain old Python versions like 2.6 or 3.3
*today* – but just for developers who need to test backwards
compatibility of their upstream libraries; we don't want to see them
used as a base for Fedora packages. Why? To make sure Fedora
packages work with modern Python, and to have only one
time-sensitive place to concentrate on when a critical security fix
comes. We want to put Python 2.7 in the same situation.
Sorry I'm a late to this thread. Have you considered making the
"legacy" python 2.7 a module? This would provide a clear way to define
the lifecycle and service level expectations.
But it's not python2 itself going that is really the painful part of
this ... it's the various python2-* packages going bye-bye as
maintainers (are already) dropping them... even when they still work.

Having a module of python2 does nothing at all to solve the actual bit
of pain we are already facing.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject
Matthew Miller
2018-04-05 15:02:19 UTC
Permalink
Post by James Hogarth
But it's not python2 itself going that is really the painful part of
this ... it's the various python2-* packages going bye-bye as
maintainers (are already) dropping them... even when they still work.
Having a module of python2 does nothing at all to solve the actual bit
of pain we are already facing.
I'm imagining all those dependent packages _also_ moving to that
module....

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@l
James Hogarth
2018-04-05 16:03:24 UTC
Permalink
Post by Matthew Miller
Post by James Hogarth
But it's not python2 itself going that is really the painful part of
this ... it's the various python2-* packages going bye-bye as
maintainers (are already) dropping them... even when they still work.
Having a module of python2 does nothing at all to solve the actual bit
of pain we are already facing.
I'm imagining all those dependent packages _also_ moving to that
module....
Sorry Matthew but I can't see that actually happening at all...

If they are already leaping to drop python2-* way ahead of the proposed EOL
of 2020 when there is no extra effort to include the subpackage in their
"normal" koiji+bodhi workflow for the main repos... why would they go to
the extra effort of a special split to do that (no longer simple
subpackage) into a module?
Matthew Miller
2018-04-05 17:27:49 UTC
Permalink
Post by James Hogarth
Post by Matthew Miller
I'm imagining all those dependent packages _also_ moving to that
module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL
of 2020 when there is no extra effort to include the subpackage in their
"normal" koiji+bodhi workflow for the main repos... why would they go to
the extra effort of a special split to do that (no longer simple
subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be
quite a pain for packages where python 2 bindings are subpackages.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@li
James Hogarth
2018-04-05 19:06:00 UTC
Permalink
Post by Matthew Miller
Post by James Hogarth
Post by Matthew Miller
I'm imagining all those dependent packages _also_ moving to that
module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed
EOL
Post by James Hogarth
of 2020 when there is no extra effort to include the subpackage in their
"normal" koiji+bodhi workflow for the main repos... why would they go to
the extra effort of a special split to do that (no longer simple
subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be
quite a pain for packages where python 2 bindings are subpackages.
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Heh just saw this one from a comment on Reddit...

https://bugs.launchpad.net/calibre/+bug/1714107

Unless Nirik does a "maintainer patch" porting the entire code over himself
I guess no more Calibre in F30 ;)
Fabio Valentini
2018-04-05 20:53:03 UTC
Permalink
Post by James Hogarth
Post by Matthew Miller
Post by James Hogarth
Post by Matthew Miller
I'm imagining all those dependent packages _also_ moving to that
module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL
of 2020 when there is no extra effort to include the subpackage in their
"normal" koiji+bodhi workflow for the main repos... why would they go to
the extra effort of a special split to do that (no longer simple
subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be
quite a pain for packages where python 2 bindings are subpackages.
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself
I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself."
Best laugh I had today.


But that's beside the point.
I just wanted to throw in something that I don't quite understand
about this thread:

If I understand correctly, the original proposal was about
- dropping python2 support and sub-packages only in "fedora > 29" or
"fedora >= 29" (see the original mail in this thread),
- starting from leaf packages, so no unmet dependencies are introduced
during the retirement process.

According to this, the python2 bindings for firewalld shouldn't have
been dropped from f28 at all, because
- there's still something depending on them (ansible support for
firewalld, still uses python2 on f28), and
- the change was explicitly about f29+ (and not f28, too).

Please correct me if I am wrong.

If I am correct though, it looks like the rawhide change to remove the
python2 sub-package from firewalld was mistakenly merged from rawhide
into f28, and should be reverted.

Fabio
Post by James Hogarth
_______________________________________________
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-lea
Eric Garver
2018-04-06 00:10:36 UTC
Permalink
Post by Fabio Valentini
Post by James Hogarth
Post by Matthew Miller
Post by James Hogarth
Post by Matthew Miller
I'm imagining all those dependent packages _also_ moving to that
module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL
of 2020 when there is no extra effort to include the subpackage in their
"normal" koiji+bodhi workflow for the main repos... why would they go to
the extra effort of a special split to do that (no longer simple
subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be
quite a pain for packages where python 2 bindings are subpackages.
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself
I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself."
Best laugh I had today.
But that's beside the point.
I just wanted to throw in something that I don't quite understand
If I understand correctly, the original proposal was about
- dropping python2 support and sub-packages only in "fedora > 29" or
"fedora >= 29" (see the original mail in this thread),
- starting from leaf packages, so no unmet dependencies are introduced
during the retirement process.
According to this, the python2 bindings for firewalld shouldn't have
been dropped from f28 at all, because
- there's still something depending on them (ansible support for
firewalld, still uses python2 on f28), and
This dependency is not visible via rpm, because it's on the remote side
not the controller side where Ansible is installed.
i.e.

$ repoquery --whatrequires python2-firewall

yields nothing. As such, I missed this indirect dependency. It would be
nice if there was a way to express this.

Correct me if I'm wrong, but won't this be a nuisance in Ansible for
some time? If the controller side (regardless of distro) defaults to
invoking python2 on the remote then it will fail on f29+. I guess
Ansible has knobs to tell it to use python3 on a set of remotes.
Alternatively you can install python3-ansible.

My point is, restoring the python2-firewall subpackage for f28 will help
targets that are f28. But in f29, the package will definitely be gone
and we're still "broken" for many controlling distros including older
Fedora releases.
Post by Fabio Valentini
- the change was explicitly about f29+ (and not f28, too).
I had dropped the python2-firewall subpackage before this thread was
started.
Post by Fabio Valentini
Please correct me if I am wrong.
If I am correct though, it looks like the rawhide change to remove the
python2 sub-package from firewalld was mistakenly merged from rawhide
into f28, and should be reverted.
I'm not an Ansible user so I don't know how painful it is for the
python2-firewall subpackage to be gone. If the majority thinks it should
be restored, then we'll bring it back.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorap
James Hogarth
2018-04-06 10:03:37 UTC
Permalink
Post by Eric Garver
Post by Fabio Valentini
Post by James Hogarth
Post by Matthew Miller
Post by James Hogarth
Post by Matthew Miller
I'm imagining all those dependent packages _also_ moving to that
module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL
of 2020 when there is no extra effort to include the subpackage in their
"normal" koiji+bodhi workflow for the main repos... why would they go to
the extra effort of a special split to do that (no longer simple
subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be
quite a pain for packages where python 2 bindings are subpackages.
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself
I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself."
Best laugh I had today.
But that's beside the point.
I just wanted to throw in something that I don't quite understand
If I understand correctly, the original proposal was about
- dropping python2 support and sub-packages only in "fedora > 29" or
"fedora >= 29" (see the original mail in this thread),
- starting from leaf packages, so no unmet dependencies are introduced
during the retirement process.
According to this, the python2 bindings for firewalld shouldn't have
been dropped from f28 at all, because
- there's still something depending on them (ansible support for
firewalld, still uses python2 on f28), and
This dependency is not visible via rpm, because it's on the remote side
not the controller side where Ansible is installed.
i.e.
$ repoquery --whatrequires python2-firewall
yields nothing. As such, I missed this indirect dependency. It would be
nice if there was a way to express this.
Correct me if I'm wrong, but won't this be a nuisance in Ansible for
some time? If the controller side (regardless of distro) defaults to
invoking python2 on the remote then it will fail on f29+. I guess
Ansible has knobs to tell it to use python3 on a set of remotes.
Alternatively you can install python3-ansible.
My point is, restoring the python2-firewall subpackage for f28 will help
targets that are f28. But in f29, the package will definitely be gone
and we're still "broken" for many controlling distros including older
Fedora releases.
Post by Fabio Valentini
- the change was explicitly about f29+ (and not f28, too).
I had dropped the python2-firewall subpackage before this thread was
started.
Post by Fabio Valentini
Please correct me if I am wrong.
If I am correct though, it looks like the rawhide change to remove the
python2 sub-package from firewalld was mistakenly merged from rawhide
into f28, and should be reverted.
I'm not an Ansible user so I don't know how painful it is for the
python2-firewall subpackage to be gone. If the majority thinks it should
be restored, then we'll bring it back.
Just align the drop to F29, at the earliest, to align with ansible
itself changing ... and let's get a Change listed (or ask the ansible
team to note this on their change) so that at least there's
documentation ...

The only real problem right now is a lack of communication in
python2-* drops ... we just need to be a lot clearer there.

Note the latest ansible documentation actually states:

Requires the python2 bindings of firewalld, which may not be installed
by default if the distribution switched to python 3

Also there is a PyPi package for firewall that is completely different
from this making things even messier as if firewalld drops the
subpackage there is no way for someone to get a py2 firewalld library
on the target system in the event their ansible module doesn't work
with py3

This is going to be a very messy couple of Fedora releases I fear ...
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe se
Kevin Fenzi
2018-04-07 20:11:41 UTC
Permalink
On 04/05/2018 05:10 PM, Eric Garver wrote:

...snip...
Post by Eric Garver
Correct me if I'm wrong, but won't this be a nuisance in Ansible for
some time? If the controller side (regardless of distro) defaults to
invoking python2 on the remote then it will fail on f29+. I guess
Ansible has knobs to tell it to use python3 on a set of remotes.
Yes, you can set a variable to tell ansible what the path is to the
python you want to use on the target. So, for newer fedora's they should
set this likely to python3.
Post by Eric Garver
Alternatively you can install python3-ansible.
Well, that will cause the host side to use python3, but not the target.
Post by Eric Garver
My point is, restoring the python2-firewall subpackage for f28 will help
targets that are f28. But in f29, the package will definitely be gone
and we're still "broken" for many controlling distros including older
Fedora releases.
Yeah, there isn't an easy answer here. I suppose we could change the
default target ansible to python3 in f29+, that would help Fedora
installs, but then mixed installs would have to change say RHEL7 targets
to use python2, so it becomes a mix... we don't know what the mix of
hosts people target are.
Post by Eric Garver
I'm not an Ansible user so I don't know how painful it is for the
python2-firewall subpackage to be gone. If the majority thinks it should
be restored, then we'll bring it back.
IMHO, people can just set the target host(s) to use python3 now, as they
are going to have to do this sooner or later.

kevin
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel
Charalampos Stratakis
2018-04-06 09:10:02 UTC
Permalink
----- Original Message -----
Sent: Thursday, April 5, 2018 10:53:03 PM
Subject: Re: Intent to orphan Python 2
Post by James Hogarth
Post by Matthew Miller
Post by James Hogarth
Post by Matthew Miller
I'm imagining all those dependent packages _also_ moving to that
module....
Sorry Matthew but I can't see that actually happening at all...
If they are already leaping to drop python2-* way ahead of the proposed EOL
of 2020 when there is no extra effort to include the subpackage in their
"normal" koiji+bodhi workflow for the main repos... why would they go to
the extra effort of a special split to do that (no longer simple
subpackage) into a module?
Yeah, it would make sense where it's a pure-python python 2 lib, but be
quite a pain for packages where python 2 bindings are subpackages.
--
Matthew Miller
Fedora Project Leader
_______________________________________________
Heh just saw this one from a comment on Reddit...
https://bugs.launchpad.net/calibre/+bug/1714107
Unless Nirik does a "maintainer patch" porting the entire code over himself
I guess no more Calibre in F30 ;)
"I am perfectly capable of maintaining python 2 myself."
Best laugh I had today.
But that's beside the point.
I just wanted to throw in something that I don't quite understand
If I understand correctly, the original proposal was about
- dropping python2 support and sub-packages only in "fedora > 29" or
"fedora >= 29" (see the original mail in this thread),
- starting from leaf packages, so no unmet dependencies are introduced
during the retirement process.
According to this, the python2 bindings for firewalld shouldn't have
been dropped from f28 at all, because
- there's still something depending on them (ansible support for
firewalld, still uses python2 on f28), and
- the change was explicitly about f29+ (and not f28, too).
Please correct me if I am wrong.
I would say that this is up to the discretion of each individual maintainer.

As packagers tend to check the dependencies on the RPM level and in this case
nothing actually required python2-firewalld when querying the repos, how would
the packager know that there are somehow other things that depend on it
which are not listed anywhere?

On a relevant note, python packaging guidelines are soon subject for a change in regards to that [0]

[0] https://pagure.io/packaging-committee/issue/753
If I am correct though, it looks like the rawhide change to remove the
python2 sub-package from firewalld was mistakenly merged from rawhide
into f28, and should be reverted.
Fabio
Post by James Hogarth
_______________________________________________
_______________________________________________
--
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedo
Jason L Tibbitts III
2018-04-06 15:33:04 UTC
Permalink
CS> On a relevant note, python packaging guidelines are soon subject for
CS> a change in regards to that [0]

CS> [0] https://pagure.io/packaging-committee/issue/753

Please note that the ticket there started off as a strong discouragement
of python2 packaging, but what was actually approved (and hopefully
today will be written into the guidelines by me) is simply an extra note
that maintainers are not required to package for python2 if they don't
want to (which really isn't a change in packaging policy at all). So
don't read the ticket title and believe that FPC has approved a blanket
ban of python2 subpackages.

To be completely honest, if someone wants to drop a python2 subpackage,
that's their prerogative but it does bring up an interesting question.
Normally if someone wants to orphan a package, they're welcome to do so
and others are welcome to pick it up. But this is about removing a
subpackage. If PackagerA wants to drop python2, but PackagerB wants to
volunteer to maintain it, the only options I see are:

* PackagerB offers to co-maintain the package, which will result in
PackagerA having to deal with the python2 subpackage anyway.

* The python2 subpackage gets generated by a separate python2-foo source
RPM that PackagerB maintains, and the original source package becomes
completely free of python2 stuff.

It may be useful to see if FPC will approve a blanket exception to the
review process for splitting python2-* source packages out of python-*
source packages, so that bit of bureaucracy can be skipped.

- J<
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscr
Zbigniew Jędrzejewski-Szmek
2018-04-07 13:53:39 UTC
Permalink
Post by Jason L Tibbitts III
To be completely honest, if someone wants to drop a python2 subpackage,
that's their prerogative but it does bring up an interesting question.
Normally if someone wants to orphan a package, they're welcome to do so
and others are welcome to pick it up. But this is about removing a
subpackage.
Yes, but as with any removal action, it behooves the maintainer to
query and think if that removal will not cause disruption, and if it
will, what is the best way to proceed (announce more widely, warn and
delay the removal, postpone indefinitely?).
Post by Jason L Tibbitts III
If PackagerA wants to drop python2, but PackagerB wants to
* The python2 subpackage gets generated by a separate python2-foo source
RPM that PackagerB maintains, and the original source package becomes
completely free of python2 stuff.
It may be useful to see if FPC will approve a blanket exception to the
review process for splitting python2-* source packages out of python-*
source packages, so that bit of bureaucracy can be skipped.
Please don't. This is a repeat of the original idea of having separate
python3 packages back when python3 was being introduced. This was always
a huge pain and waste of maintainer time. From my perspective the idea
of separate python3 source packages held back the support for python3
in Fedora by a year or two.

Doing this on any massive scale would means hundreds (up to 2800?)
"new" packages, a way to burn massive amounts of maintainer time.
Post by Jason L Tibbitts III
* PackagerB offers to co-maintain the package, which will result in
PackagerA having to deal with the python2 subpackage anyway.
Let's do this instead. We need more co-maintainership and more
co-operation in Fedora. If there are people who want or need to support
the python2 version, I'm sure we can have informal agreements where
the bugs with python2 get assigned to them. Keeping an exisiting
python2 subpackage is really no big deal.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deve
Miro Hrončok
2018-04-07 14:15:15 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Jason L Tibbitts III
To be completely honest, if someone wants to drop a python2 subpackage,
that's their prerogative but it does bring up an interesting question.
Normally if someone wants to orphan a package, they're welcome to do so
and others are welcome to pick it up. But this is about removing a
subpackage.
Yes, but as with any removal action, it behooves the maintainer to
query and think if that removal will not cause disruption, and if it
will, what is the best way to proceed (announce more widely, warn and
delay the removal, postpone indefinitely?).
So apparently the general confusion/problem here is lack of
communication when removing python2-subpackages.

Filling a Fedora Change proposal for every single python2 subpackage
removal feels a bit overengineered. So let's set up some basic rules
about what to do when a python2 subpackage is being removed. E.g. do it
in rawhide only, send an announcement do devel, wait X days, etc.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@
Zbigniew Jędrzejewski-Szmek
2018-04-07 14:33:16 UTC
Permalink
Post by Miro Hrončok
Post by Zbigniew Jędrzejewski-Szmek
Post by Jason L Tibbitts III
To be completely honest, if someone wants to drop a python2 subpackage,
that's their prerogative but it does bring up an interesting question.
Normally if someone wants to orphan a package, they're welcome to do so
and others are welcome to pick it up. But this is about removing a
subpackage.
Yes, but as with any removal action, it behooves the maintainer to
query and think if that removal will not cause disruption, and if it
will, what is the best way to proceed (announce more widely, warn and
delay the removal, postpone indefinitely?).
So apparently the general confusion/problem here is lack of
communication when removing python2-subpackages.
Filling a Fedora Change proposal for every single python2 subpackage
removal feels a bit overengineered. So let's set up some basic rules
about what to do when a python2 subpackage is being removed. E.g. do
it in rawhide only, send an announcement do devel, wait X days, etc.
For timing, I think should piggy-back on the rules for retiring. From
user POV, there isn't much difference between a subpackage disappearing
Post by Miro Hrončok
Do not retire packages in other branches than Branched (until the
Final Freeze), Rawhide (master) and EPEL branches (el5, el6, epel7).
When you need to add package from EPEL to any RHEL release, only
retire EPEL branch when package is released in that RHEL release.
+1 for fedora-devel. A mail to fedora-devel a week in advance should
be enough. And if people show up who want to take responsibility for
the python2 version, give them ACLs.

[1] https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe se
Kevin Kofler
2018-04-07 16:45:06 UTC
Permalink
Post by Miro Hrončok
So apparently the general confusion/problem here is lack of
communication when removing python2-subpackages.
Filling a Fedora Change proposal for every single python2 subpackage
removal feels a bit overengineered. So let's set up some basic rules
about what to do when a python2 subpackage is being removed. E.g. do it
in rawhide only, send an announcement do devel, wait X days, etc.
How about just NOT removing the subpackage to begin with if there is no
strong reason to (such as upstream dropping support)?

It is not even clear at this time that python2 will really end up eradicated
and not picked up as e.g. qt3 was. Removing the python2-* subpackages just
because they depend on python2 is a very premature move.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscri
Miro Hrončok
2018-04-07 18:16:40 UTC
Permalink
On 7.4.2018 18:45, Kevin Kofler wrote> How about just NOT removing the
subpackage to begin with if there is no
Post by Kevin Kofler
strong reason to (such as upstream dropping support)?
The strong reason for me as a packager might be "I don't want to
maintain this crap anymore, I see no benefit in it."

Strong reasons for the distribution were already discussed above, including:

* we don't have the ability/mapower to remove everything at once
* by removing stuff gradually, we have longer time period to fix any
issues that it brings

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-l
Peter Oliver
2018-04-08 11:19:16 UTC
Permalink
Post by Miro Hrončok
* we don't have the ability/mapower to remove everything at once
Won't it take more total effort to remove things piecemeal rather than all
in one go, though?

* by removing stuff gradually, we have longer time period to fix any
Post by Miro Hrončok
issues that it brings
My understanding was that it's now too late to remove things from Fedora
28, and we want Python 2 gone by the time Fedora 30 is released. That only
gives us Fedora 29 as wiggle room, which doesn't seem all that gradual to
me.

In any case, once we start removing Python 2 components, it seems to me
that the message to users is, "Python 2 can't be relied upon in this
release". That being the case, if we did go ahead with this staged
removal, would it be helpful to think of this change the other way around?
Rather than removing Python 2 from Fedora 30 but starting that work during
Fedora 29, we're removing it from Fedora 29 but not completing all of that
work until Fedora 30?
--
Peter Oliver
Kevin Kofler
2018-04-08 15:22:34 UTC
Permalink
Post by Peter Oliver
In any case, once we start removing Python 2 components, it seems to me
that the message to users is, "Python 2 can't be relied upon in this
release". That being the case, if we did go ahead with this staged
removal, would it be helpful to think of this change the other way around?
Rather than removing Python 2 from Fedora 30 but starting that work during
Fedora 29, we're removing it from Fedora 29 but not completing all of that
work until Fedora 30?
Who says Python 2 is going to be removed from Fedora 30 at all? I think this
is a completely unrealistic target. Somebody needs to pick it up. It will
not be much effort. There will at some point be no new upstream releases, so
almost zero packaging work. All that is to do is to pick up the security
backports from RHEL/CentOS. I see no benefit from removing the python2
package in such a rush.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fe
Rex Dieter
2018-04-08 15:32:11 UTC
Permalink
Post by Kevin Kofler
Somebody needs to pick it up.
...
I see no benefit from removing the python2
package in such a rush.
And we've circled back to the original post starting this thread.

Note: intent to *orphan*, not intent to *retire*.

-- Rex
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email t
Kevin Kofler
2018-04-08 15:49:26 UTC
Permalink
Post by Rex Dieter
And we've circled back to the original post starting this thread.
Note: intent to *orphan*, not intent to *retire*.
If it is not going to be retired, then why would we want to kill python2-*
subpackages throughout the distribution for no reason?

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fe
Nico Kadel-Garcia
2018-04-08 15:57:10 UTC
Permalink
Post by Kevin Kofler
Post by Rex Dieter
And we've circled back to the original post starting this thread.
Note: intent to *orphan*, not intent to *retire*.
If it is not going to be retired, then why would we want to kill python2-*
subpackages throughout the distribution for no reason?
Kevin Kofler
Maintaining code that isn't used means maintaining code you don't
test. Discarding support for unused code means that authors of Python
modules can test a single set of dependencies.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproj
Petr Viktorin
2018-04-09 11:39:59 UTC
Permalink
Post by Kevin Kofler
Post by Rex Dieter
And we've circled back to the original post starting this thread.
Note: intent to *orphan*, not intent to *retire*.
If it is not going to be retired, then why would we want to kill python2-*
subpackages throughout the distribution for no reason?
By orphaning, I mean:

1. Work with users and maintainers of dependent packages to either
remove their dependencies or to share/take over maintainership
2. Drop the package if no one stepped up

This is the first step.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai
Jason L Tibbitts III
2018-04-09 05:55:04 UTC
Permalink
ZJ> Please don't. This is a repeat of the original idea of having
ZJ> separate python3 packages back when python3 was being
ZJ> introduced.

It seems that you are suggesting that pointless bureaucracy be kept in
place purely because it slows down a process which you don't personally
like. If so, that's awfully passive-aggressive.

If someone does wish too create a separate python2 package via a package
review, will you also attempt to obstruct that review?

ZJ> This was always a huge pain and waste of maintainer time.

I'm somewhat confused; you seem to wish to make it take more time, not
less.

ZJ> Doing this on any massive scale would means hundreds (up to 2800?)
ZJ> "new" packages, a way to burn massive amounts of maintainer time.

Has anyone at all suggested doing this on a massive scale? I certainly
didn't. I only suggested making it easier to handle the case where a
package maintainer simply doesn't want the python2 subpackage to be
generated from the main package. I get the impression you took my
suggestion and for whatever reason turned it into something else
entirely.

ZJ> Let's do this instead. We need more co-maintainership and more
ZJ> co-operation in Fedora.

But it has all of the problems I outlined.

ZJ> Keeping an exisiting python2 subpackage is really no big deal.

Perhaps for you. Perhaps not for others. If it was no big deal in all
cases then why have any python2 packages been dropped at all?

- J<
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fe
Zbigniew Jędrzejewski-Szmek
2018-04-09 07:29:23 UTC
Permalink
Post by Jason L Tibbitts III
ZJ> Please don't. This is a repeat of the original idea of having
ZJ> separate python3 packages back when python3 was being
ZJ> introduced.
It seems that you are suggesting that pointless bureaucracy be kept in
place purely because it slows down a process which you don't personally
like. If so, that's awfully passive-aggressive.
If someone does wish too create a separate python2 package via a package
review, will you also attempt to obstruct that review?
This is a misunderstanding. I wasn't speaking against the proposal
to have a fast-track review process. I was speaking against the proposal
to make those separate packages at all.

(If people create a separate package for python2 after all, I'm fine
with an expedited review.)
Post by Jason L Tibbitts III
ZJ> This was always a huge pain and waste of maintainer time.
I'm somewhat confused; you seem to wish to make it take more time, not
less.
ZJ> Doing this on any massive scale would means hundreds (up to 2800?)
ZJ> "new" packages, a way to burn massive amounts of maintainer time.
Has anyone at all suggested doing this on a massive scale? I certainly
didn't. I only suggested making it easier to handle the case where a
package maintainer simply doesn't want the python2 subpackage to be
generated from the main package. I get the impression you took my
suggestion and for whatever reason turned it into something else
entirely.
ZJ> Let's do this instead. We need more co-maintainership and more
ZJ> co-operation in Fedora.
But it has all of the problems I outlined.
ZJ> Keeping an exisiting python2 subpackage is really no big deal.
Perhaps for you. Perhaps not for others. If it was no big deal in all
cases then why have any python2 packages been dropped at all?
That's a good question. So far I have seen the following:
1. dropping python2 support in leaf packages gradually and fix any
issues one-by-one is easier then doing it in one step and then
trying to rebuild everything.
2. dropping python2 support gradually makes people notice and raises
awareness that they need to wean off python2. This applies to
maintainers and non-maintainers alike.
3. removing support for python2 reduces maintenance burden.
4. apparently people don't like python2 and don't want to deal with it.

I share the sentiment behind all four points and I think they are all
valid. The problem of when to remove support is to a large extent a
matter of pushing work around. Removing support for python2 from a
package makes life a bit easier for the maintainers of that package,
and a bit harder for maintainers of dependent packages, and users. In
my experience, the work to keep support for python2 at an existing
level is not high, so when looking at the level of the whole distro,
the positive gain from dropping support is smaller than the negative
gain for people who have to update for that lost support. Thus, my
feeling is that right now, it's better to keep it. If something major
happens, like package upstream stopping support for python2, or
dependencies going away, then there's a good reason to stop supporting
python2.

Zbyszek
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorapr
Miro Hrončok
2018-07-16 18:15:27 UTC
Permalink
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Fedora still has more than 3000 packages depending on python2 – many
more than we can support without upstream help.
We (rightly) don't have the authority to say "please drop your unneeded
python2 subpackages, or let us drop them for you" [0].
The next best thing we *can* say is: "if Fedora is to keep python2
alive, we won't be the ones doing it – at least not at the current
magnitude".
Here are the details.
The current maintainers of python2 would like to "orphan" the python2
- Charalampos Stratakis (cstratak)
- Tomáš Orsava (torsava)
- Miro Hrnočok (churchyard)
- Petr Viktorin (pviktori)
- Iryna Schcherbina (ishcherb)
- Michal Cyprian (mcyprian)
- Bohuslav Kabrda (bkabrda)
- David Malcolm (dmalcolm)
- Thomas Spura (tomspur)
- someone else agrees now to take over in 2020 (keeping in mind this is
a security-critical package and will be abandoned upstream), or
- dependent packages drop support for Python 2.
Unlike most other orphanings, we have some thousands of dependent
packages, so a lot of time and care is required.
In case no one steps up, we'd like to start dropping Python 2 support
from dependent packages *now*, starting with ported libraries on whose
python2 version nothing in Fedora depends. (We keep a list of those at [1].)
Of course, we're ready to make various compromises with interested
packagers, as long as there's an understanding that we won't just
support python2 forever.
If you are a maintainer of anything at [1] we ask you kindly to consider
removing the python2 subpackages.
You can either do it now in Rawhide, or add a conditional for Fedora >
29. (On the current schedule, Fedora 30 will be the first release still
supported after 2020-01-01.)
If no one steps up to maintain python2 after 2020, we're prepared to
package a "legacy" python27 package, similar to what we do for e.g.
- help developers that still need to test against this version
- support exceptionally important non–security critical applications, if
their upstreams don't manage to port to Python 3 in time
[0] https://pagure.io/packaging-committee/issue/753
[1] http://fedora.portingdb.xyz/#legacy-leaf
[2] https://src.fedoraproject.org/rpms/python33/
This is just a reminder that nobody stepped up to maintain Python 2
after 2020. We still need to start dropping python2 packages.

What shall we do from here? File a Fedora System Wide Change Proposal
for Fedora 30 that nothing explicitly white-listed to require Python 2
will be removed from Fedora? Can we even do that?

For context - there are currently 708 leaf packages [1](above).

Except several tools and applications, those are all modules that
nothing in Fedora depends on. If we remove some, others only required by
them will become leaf-packages as well.

We also have 1220 py2 only packages out of which plenty are probably
unneeded modules as well, although we don't have the numbers.

As stated in the above e-mail in March, we are willing to support
python2 for several (small number) of tools or apps. But we will not
support it for 3 thousands of unused, unknown modules.

Python 2 will EOL in less than 1.5 year.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraprojec
R P Herrold
2018-07-16 18:57:11 UTC
Permalink
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious.
Not ALL packages become unsupported that first day of that
year
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary
maintenance date (through 2020 11 30) a closer maintenance
depot to look at and to compare against ?

Packages NOT in RHEL have a closer date, perhaps, but RHEL
(next, assumedly 8, but ...) has not dropped yet. A
subscription customer _should_ be migrating toward 7 at this
point, but as this is not a costless thing, such migrations
tend to be ... with a deliberate pace

-- Russ herrold
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/V6TXSNJ7ER4S
Charalampos Stratakis
2018-07-16 22:18:27 UTC
Permalink
----- Original Message -----
Sent: Monday, July 16, 2018 8:57:11 PM
Subject: Re: Intent to orphan Python 2
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious.
Not ALL packages become unsupported that first day of that
year
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary
maintenance date (through 2020 11 30) a closer maintenance
depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
Packages NOT in RHEL have a closer date, perhaps, but RHEL
(next, assumedly 8, but ...) has not dropped yet. A
subscription customer _should_ be migrating toward 7 at this
point, but as this is not a costless thing, such migrations
tend to be ... with a deliberate pace
Agreed but yet again, this doesn't like something that would impact Fedora.
-- Russ herrold
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
--
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/DAHZTVERHGRCASAXAL5UOBXJQE
Nico Kadel-Garcia
2018-07-17 12:16:55 UTC
Permalink
On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis
Post by Charalampos Stratakis
----- Original Message -----
Sent: Monday, July 16, 2018 8:57:11 PM
Subject: Re: Intent to orphan Python 2
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious.
Not ALL packages become unsupported that first day of that
year
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary
maintenance date (through 2020 11 30) a closer maintenance
depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
EPEL. Many of us use EPEL, with components from Fedora backported to
our working environments. It's been an invaluable resource. Me? I just
got a good look at openstack,, as well, which solved a *lot* of
problems for me trying to bring some modules for communicating with
proprietary data appliances into a RHEL environment. It's part of why
so many Python modules have bothered to maintain Python 2 and Python 3
versions.
Post by Charalampos Stratakis
Packages NOT in RHEL have a closer date, perhaps, but RHEL
(next, assumedly 8, but ...) has not dropped yet. A
subscription customer _should_ be migrating toward 7 at this
point, but as this is not a costless thing, such migrations
tend to be ... with a deliberate pace
Agreed but yet again, this doesn't like something that would impact Fedora.
A lot of us use Fedora as a testing ground for our commercial work for
the more RHEL and CentOS, and a source of bleeding edge tools. Good
open source work is usually open to supporting multiple environments,
so it's worth a thought.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.or
Miro Hrončok
2018-07-17 17:43:05 UTC
Permalink
Post by Nico Kadel-Garcia
On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis
Post by Charalampos Stratakis
----- Original Message -----
Sent: Monday, July 16, 2018 8:57:11 PM
Subject: Re: Intent to orphan Python 2
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious.
Not ALL packages become unsupported that first day of that
year
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary
maintenance date (through 2020 11 30) a closer maintenance
depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
EPEL. Many of us use EPEL, with components from Fedora backported to
our working environments. It's been an invaluable resource. Me? I just
got a good look at openstack,, as well, which solved a *lot* of
problems for me trying to bring some modules for communicating with
proprietary data appliances into a RHEL environment. It's part of why
so many Python modules have bothered to maintain Python 2 and Python 3
versions.
I hear you. I just don't understand what our action shall be according
to you. Having python2 in Fedora might indeed be beneficial to old EPELs
(and RHELs). But it shall not be an excuse to have thousands of modules
packaged and supported because some of them might (or might not be) also
present in EPEL. You can even use python3 in EPEL and call it a day.
Post by Nico Kadel-Garcia
Post by Charalampos Stratakis
Packages NOT in RHEL have a closer date, perhaps, but RHEL
(next, assumedly 8, but ...) has not dropped yet. A
subscription customer _should_ be migrating toward 7 at this
point, but as this is not a costless thing, such migrations
tend to be ... with a deliberate pace
Agreed but yet again, this doesn't like something that would impact Fedora.
A lot of us use Fedora as a testing ground for our commercial work for
the more RHEL and CentOS, and a source of bleeding edge tools. Good
open source work is usually open to supporting multiple environments,
so it's worth a thought.
I (and now I'm speaking strictly for myself, other Fedora Python
maintainers might have different opinion) won't spend my free time to
maintain something I don't like just to support your commercial work.
Will you? I don't have enough resources in my paid time to support
Python 2 in Fedora **on the current scale**. That's what this topic was
all about. Reduce the cruft, so we can keep it and support it in our
paid time to support both commercial and non-commercial work. If not
reduced, we cannot do that.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/N772E3ATIRLK
Nico Kadel-Garcia
2018-07-18 03:11:54 UTC
Permalink
Post by Nico Kadel-Garcia
On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis
Post by Charalampos Stratakis
----- Original Message -----
To: "Development discussions related to Fedora"
Sent: Monday, July 16, 2018 8:57:11 PM
Subject: Re: Intent to orphan Python 2
Post by Petr Viktorin
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need
to start dropping python2 packages now.
tl;dr: --- that statement by itself overlooks the obvious.
Not ALL packages become unsupported that first day of that
year
Post by Petr Viktorin
Python 2.7 will reach end of upstream support on 1st of January, 2020,
after almost 10 years (!) of volunteer maintenance.
Not to be too direct about this, but isn't the RHEL 6 primary
maintenance date (through 2020 11 30) a closer maintenance
depot to look at and to compare against ?
I don't see how that relates to Fedora. Could you elaborate on what you mean?
EPEL. Many of us use EPEL, with components from Fedora backported to
our working environments. It's been an invaluable resource. Me? I just
got a good look at openstack,, as well, which solved a *lot* of
problems for me trying to bring some modules for communicating with
proprietary data appliances into a RHEL environment. It's part of why
so many Python modules have bothered to maintain Python 2 and Python 3
versions.
I hear you. I just don't understand what our action shall be according to
you. Having python2 in Fedora might indeed be beneficial to old EPELs (and
RHELs). But it shall not be an excuse to have thousands of modules packaged
and supported because some of them might (or might not be) also present in
EPEL. You can even use python3 in EPEL and call it a day.
I was explaining why reasonable people involved in Fedora would care.
I'm not saying never do it. It also happened with the perl 4 to perl 5
upgrade, for those of us who remember that, and when apache 1.x became
httpd 2.x, and when Ruby updated to 2.x. Parallel support is possible
and sometimes necessary.

What's happening now with Python has been pretty good, and I applaud
the maintainers who've been forwarding Python 2 modules and the
occasionally messy but overall effective logic of building parallel
python2 and python3 modules. Python 2 *does* need to be replaced as
the default. And I think at some point the logic will need to be
reversed, that "with_python2" becomes the flag needed for building
those older package, instead of the current "with_python3". That is
going to be a pain in the *fundament* to port.
I (and now I'm speaking strictly for myself, other Fedora Python maintainers
might have different opinion) won't spend my free time to maintain something
I don't like just to support your commercial work. Will you? I don't have
enough resources in my paid time to support Python 2 in Fedora **on the
current scale**. That's what this topic was all about. Reduce the cruft, so
we can keep it and support it in our paid time to support both commercial
and non-commercial work. If not reduced, we cannot do that.
Your logic is sound. I publish patches to Fedora authors out of
enlightened self interest for my paid work with RHEL and CentOS, and
occasionally for the challenge of getting stuff into the bleeding edge
systems. When RHEL 8 comes out, I hope it will be Python 3 based and
I'll have the tools to mostly ignore Python 2, fostered by the good
work happening in Fedora.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org
Kevin Fenzi
2018-07-17 22:03:00 UTC
Permalink
Post by Miro Hrončok
This is just a reminder that nobody stepped up to maintain Python 2
after 2020. We still need to start dropping python2 packages.
What shall we do from here? File a Fedora System Wide Change Proposal
for Fedora 30 that nothing explicitly white-listed to require Python 2
will be removed from Fedora? Can we even do that?
How would you construct the whitelist?
Post by Miro Hrončok
For context - there are currently 708 leaf packages [1](above).
Except several tools and applications, those are all modules that
nothing in Fedora depends on. If we remove some, others only required by
them will become leaf-packages as well.
We also have 1220 py2 only packages out of which plenty are probably
unneeded modules as well, although we don't have the numbers.
As stated in the above e-mail in March, we are willing to support
python2 for several (small number) of tools or apps. But we will not
support it for 3 thousands of unused, unknown modules.
Python 2 will EOL in less than 1.5 year.
Could we perhaps look at moving python2 and everything that wants to use
it into a module? I think that might make it more clear that it's not
part of base Fedora and when it goes eol in f32 we drop it? That would
take a lot of effort and duplication tho.

I don't think we want to drag this out too long... a clear call to drop
all python2 in 31 (or I suppose f30) would be helpful and avoid some
people dropping something other packages need, etc.

kevin
Miro Hrončok
2018-07-17 23:35:55 UTC
Permalink
Post by Kevin Fenzi
Post by Miro Hrončok
This is just a reminder that nobody stepped up to maintain Python 2
after 2020. We still need to start dropping python2 packages.
What shall we do from here? File a Fedora System Wide Change Proposal
for Fedora 30 that nothing explicitly white-listed to require Python 2
will be removed from Fedora? Can we even do that?
How would you construct the whitelist?
Maintainers of apps and tools would whitelist their packages and we
would recursively track dependencies. But that was a bit sarcastic from
me, because I don't believe this would ever work (hence the "Can we even
do that?" part).
Post by Kevin Fenzi
Post by Miro Hrončok
For context - there are currently 708 leaf packages [1](above).
Except several tools and applications, those are all modules that
nothing in Fedora depends on. If we remove some, others only required by
them will become leaf-packages as well.
We also have 1220 py2 only packages out of which plenty are probably
unneeded modules as well, although we don't have the numbers.
As stated in the above e-mail in March, we are willing to support
python2 for several (small number) of tools or apps. But we will not
support it for 3 thousands of unused, unknown modules.
Python 2 will EOL in less than 1.5 year.
Could we perhaps look at moving python2 and everything that wants to use
it into a module? I think that might make it more clear that it's not
part of base Fedora and when it goes eol in f32 we drop it? That would
take a lot of effort and duplication tho.
That would be very painful and would request an extraordinary amount of
manpower while gaining zero benefit (except that we would have the
ability to drop it mid-realease). The drop can wait until that Fedora EOLs.
Post by Kevin Fenzi
I don't think we want to drag this out too long... a clear call to drop
all python2 in 31 (or I suppose f30) would be helpful and avoid some
people dropping something other packages need, etc.
We can call for that but we know that it is not possible. There are
Python 2 powered apps in Fedora that could seriously disturb the distro
if dropped.

To name a few:

fedora-easy-karma
fedora-packager
fedora-review
chromium
nodejs
datagrepper
datanommer
fedwatch
gimp
inkscape
mercurial
xen
...

We want to keep them and we are able to maintain Python 2 for them
(well, we would very much prefer to have them ported to Python 3 but we
realize it's not always happening.)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproj
Kevin Fenzi
2018-07-22 17:57:06 UTC
Permalink
On 07/17/2018 04:35 PM, Miro Hrončok wrote:
...snip...
Post by Miro Hrončok
We want to keep them and we are able to maintain Python 2 for them
(well, we would very much prefer to have them ported to Python 3 but we
realize it's not always happening.)
Well, if something is broken in python2, breaking one of the packages
you want to maintain it for, likely it's broken for other packages too?
But I see what you mean...

One of the reasons I suggested modules was that it would take concrete
work for packages that still need python2 to become modular and depend
on a python2 module, making it easier to just retire everything in the
main collection that doesn't take any action.

I think without that you are back to a whitelist... "all python2
dependent packages will be retired in F30, except the ones on this list"
and you will have to detect those.

kevin

Continue reading on narkive:
Loading...