10:17 a.m.
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/
11:17 a.m.
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.)
I notice that [1] does not update, though if you click on a specific
package, that page does update. For an example:
http://fedora.portingdb.xyz/pkg/python-xcffib/
--
Dulaney.
4:25 a.m.
On 22.3.2018 17:17, John Dulaney wrote:> I notice that [1] does not
update, though if you click on a specific
package, that page does update. For an example:
http://fedora.portingdb.xyz/pkg/python-xcffib/
What do you mean by dos not update? Might that be browser cache thing?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:15 a.m.
Something that occurred to me last night, rather than a conditional on
Fedora version, is there a macro that we could provide to mean python2 is
available in this Fedora version? That way packagers wanting to support
their packages on the versions of python that the platform ships can
conditionalize on that imstead of fedora release (which is variable
depending on whether someone picked up and drops support for the orphaned
python 2 package)
-Toshio
On Thu, Mar 22, 2018, 9:20 AM John Dulaney <jdulaney(a)gnu.org> wrote:
> 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.)
I notice that [1] does not update, though if you click on a specific
package, that page does update. For an example:
http://fedora.portingdb.xyz/pkg/python-xcffib/
--
Dulaney.
_______________________________________________
python-devel mailing list -- python-devel(a)lists.fedoraproject.org
To unsubscribe send an email to python-devel-leave(a)lists.fedoraproject.org
10:12 a.m.
On 03/23/18 15:15, Toshio Kuratomi wrote:
Something that occurred to me last night, rather than a conditional
on
Fedora version, is there a macro that we could provide to mean python2
is available in this Fedora version? That way packagers wanting to
support their packages on the versions of python that the platform ships
can conditionalize on that imstead of fedora release (which is variable
depending on whether someone picked up and drops support for the
orphaned python 2 package)
I'm not sure how useful that would be. Wouldn't we want that not only
for the python2 package, but also for other dependencies?
Django's py2 subpackage is dropped already. Should there have been a
macro advertising that?
Also, we want to *avoid* breaking everything at once. Providing a flag
that gets flipped at one moment wouldn't solve much.
10:43 a.m.
On Fri, Mar 23, 2018, 8:13 AM Petr Viktorin <pviktori(a)redhat.com> wrote:
On 03/23/18 15:15, Toshio Kuratomi wrote:
> Something that occurred to me last night, rather than a conditional on
> Fedora version, is there a macro that we could provide to mean python2
> is available in this Fedora version? That way packagers wanting to
> support their packages on the versions of python that the platform ships
> can conditionalize on that imstead of fedora release (which is variable
> depending on whether someone picked up and drops support for the
> orphaned python 2 package)
I'm not sure how useful that would be. Wouldn't we want that not only
for the python2 package, but also for other dependencies?
Django's py2 subpackage is dropped already. Should there have been a
macro advertising that?
Also, we want to *avoid* breaking everything at once. Providing a flag
that gets flipped at one moment wouldn't solve much.
_______________________________________________
Depends on what the groups of packagers want... A macro for Django would
definitely have given an easy option for packagers to take advantage of.
Otoh, how far in advance was the Django removal telegraphed and how much
chance was there that a new maintainer would pick it up? It doesn't do as
much good for a package that is going to definitely drop support in the
very next release as it does for a package that is going to drop support
two releases from now, maybe, unless someone decides to pick it up, even at
the last minute, perhaps only after they realize it's been removed from the
repository....
Why do we want to avoid *breaking* everything at once? I can see us
wanting to keep things *working* as long as it makes sense to the set of
packagers that care (which I think adding the macro would aid in) but it
doesn't feel like actively designing things to break a little at a time is
helpful to anyone. Users can't count on things working from release to
release and packagers have to do more work to keep the pieces they care
about working.
-toshio
11:26 a.m.
On Màrt 23, 2018 aig 03:43:13f +0000, Toshio Kuratomi sgrìobh:
Depends on what the groups of packagers want... A macro for Django
would
definitely have given an easy option for packagers to take advantage of.
Otoh, how far in advance was the Django removal telegraphed and how much
chance was there that a new maintainer would pick it up? It doesn't do as
much good for a package that is going to definitely drop support in the
very next release as it does for a package that is going to drop support
two releases from now, maybe, unless someone decides to pick it up, even at
the last minute, perhaps only after they realize it's been removed from the
repository....
Why do we want to avoid *breaking* everything at once? I can see us
wanting to keep things *working* as long as it makes sense to the set of
packagers that care (which I think adding the macro would aid in) but it
doesn't feel like actively designing things to break a little at a time is
helpful to anyone. Users can't count on things working from release to
release and packagers have to do more work to keep the pieces they care
about working.
I, for one, am glad to drop python2 support in everything I maintain.
In fact, I have already started doing so with packages I maintain that
do not have any dependencies that I can see on the python2 side.
--
Dulaney.
11:50 a.m.
On 03/23/18 16:43, Toshio Kuratomi wrote:
On Fri, Mar 23, 2018, 8:13 AM Petr Viktorin <pviktori(a)redhat.com
<mailto:pviktori@redhat.com>> wrote:
On 03/23/18 15:15, Toshio Kuratomi wrote:
> Something that occurred to me last night, rather than a
conditional on
> Fedora version, is there a macro that we could provide to mean
python2
> is available in this Fedora version? That way packagers wanting to
> support their packages on the versions of python that the
platform ships
> can conditionalize on that imstead of fedora release (which is
variable
> depending on whether someone picked up and drops support for the
> orphaned python 2 package)
I'm not sure how useful that would be. Wouldn't we want that not only
for the python2 package, but also for other dependencies?
Django's py2 subpackage is dropped already. Should there have been a
macro advertising that?
Also, we want to *avoid* breaking everything at once. Providing a flag
that gets flipped at one moment wouldn't solve much.
_______________________________________________
Depends on what the groups of packagers want... A macro for Django would
definitely have given an easy option for packagers to take advantage
of. Otoh, how far in advance was the Django removal telegraphed and how
much chance was there that a new maintainer would pick it up?
Um, Django set its current policy back in 2015 (see
https://www.djangoproject.com/weblog/2015/jun/25/roadmap/):
We will support a Python version up to and including the
first Django LTS release whose security support ends after
security support for that version of Python ends. For
example, Python 3.3 security support ends September 2017 and
Django 1.8 LTS security support ends April 2018. Therefore
Django 1.8 is the last version to support Python 3.3.
Fedora follows upstream, packaging the newest version (which is now
incompatible with py2). And the django-1.11 LTS release is packaged in
Fedora for Python 2, as a courtesy to projects that need a bit more time.
(Of course, instead of maintaining the LTS I could just say to kobo or
pulp that they're out of time and on their own. That's not what I want.
But I also don't want to maintain the LTS forever.)
It doesn't do as much good for a package that is going to
definitely drop
support in the very next release as it does for a package that is going
to drop support two releases from now, maybe, unless someone decides to
pick it up, even at the last minute, perhaps only after they realize
it's been removed from the repository....
Python 2 is security-critical software with thousands of dependencies.
If someone is not following along, and wakes up at the last minute to
maintain it, then I *still* want to remove as many of those dependencies
as possible -- both to make their job easier, and because I wouldn't
trust them to do a very good job.
Why do we want to avoid *breaking* everything at once? I can see us
wanting to keep things *working* as long as it makes sense to the set of
packagers that care (which I think adding the macro would aid in) but it
doesn't feel like actively designing things to break a little at a time
is helpful to anyone.
I *don't* want to support Python 2. I *do* want to give packagers a
more-than-fair change to switch to py3-only, if they haven't done so
yet. And possibly help with concrete problems they'll have when switching.
But I can't help with those problems if they appear all at once.
Python2 is used in many parts of Fedora (and beyond) that we don't *see*
until we start removing things -- build tools, infrastructure, who knows
what else. Removing these things lets us react to problems as they come up.
If everyone starts dropping the py2 subpackages *now*, starting from the
leaves, then by circa 2020 we can orphan Python 2 with clean conscience.
Users can't count on things working from release
to release and packagers have to do more work to keep the pieces they
care about working.
Sorry, but with that mindset I could just orphan Python 2 now. That
would be irresponsible.
12:41 p.m.
On Fri, Mar 23, 2018, 9:50 AM Petr Viktorin <pviktori(a)redhat.com> wrote:
On 03/23/18 16:43, Toshio Kuratomi wrote:
>
>
> On Fri, Mar 23, 2018, 8:13 AM Petr Viktorin <pviktori(a)redhat.com
> <mailto:pviktori@redhat.com>> wrote:
>
> On 03/23/18 15:15, Toshio Kuratomi wrote:
> > Something that occurred to me last night, rather than a
> conditional on
> > Fedora version, is there a macro that we could provide to mean
> python2
> > is available in this Fedora version? That way packagers wanting
to
> > support their packages on the versions of python that the
> platform ships
> > can conditionalize on that imstead of fedora release (which is
> variable
> > depending on whether someone picked up and drops support for the
> > orphaned python 2 package)
>
> I'm not sure how useful that would be. Wouldn't we want that not only
> for the python2 package, but also for other dependencies?
> Django's py2 subpackage is dropped already. Should there have been a
> macro advertising that?
>
>
> Also, we want to *avoid* breaking everything at once. Providing a
flag
> that gets flipped at one moment wouldn't solve much.
> _______________________________________________
>
> Depends on what the groups of packagers want... A macro for Django would
> definitely have given an easy option for packagers to take advantage
> of. Otoh, how far in advance was the Django removal telegraphed and how
> much chance was there that a new maintainer would pick it up?
Um, Django set its current policy back in 2015 (see
https://www.djangoproject.com/weblog/2015/jun/25/roadmap/):
We will support a Python version up to and including the
first Django LTS release whose security support ends after
security support for that version of Python ends. For
example, Python 3.3 security support ends September 2017 and
Django 1.8 LTS security support ends April 2018. Therefore
Django 1.8 is the last version to support Python 3.3.
Fedora follows upstream, packaging the newest version (which is now
incompatible with py2). And the django-1.11 LTS release is packaged in
Fedora for Python 2, as a courtesy to projects that need a bit more time.
(Of course, instead of maintaining the LTS I could just say to kobo or
pulp that they're out of time and on their own. That's not what I want.
But I also don't want to maintain the LTS forever.)
> It doesn't do as much good for a package that is going to definitely drop
> support in the very next release as it does for a package that is going
> to drop support two releases from now, maybe, unless someone decides to
> pick it up, even at the last minute, perhaps only after they realize
> it's been removed from the repository....
Python 2 is security-critical software with thousands of dependencies.
If someone is not following along, and wakes up at the last minute to
maintain it, then I *still* want to remove as many of those dependencies
as possible -- both to make their job easier, and because I wouldn't
trust them to do a very good job.
> Why do we want to avoid *breaking* everything at once? I can see us
> wanting to keep things *working* as long as it makes sense to the set of
> packagers that care (which I think adding the macro would aid in) but it
> doesn't feel like actively designing things to break a little at a time
> is helpful to anyone.
I *don't* want to support Python 2. I *do* want to give packagers a
more-than-fair change to switch to py3-only, if they haven't done so
yet. And possibly help with concrete problems they'll have when switching.
But I can't help with those problems if they appear all at once.
Python2 is used in many parts of Fedora (and beyond) that we don't *see*
until we start removing things -- build tools, infrastructure, who knows
what else. Removing these things lets us react to problems as they come up.
If everyone starts dropping the py2 subpackages *now*, starting from the
leaves, then by circa 2020 we can orphan Python 2 with clean conscience.
> Users can't count on things working from release
> to release and packagers have to do more work to keep the pieces they
> care about working.
Sorry, but with that mindset I could just orphan Python 2 now. That
would be irresponsible.
You're only reading half of what I wrote above. I was saying that it
doesn't help either those who want to keep it or those who want to drop
it. Inconsistency hurts both of those sets of people. Dropping now would
help one for the detriment of the other set. Dropping at once in the
future would be a compromise to those two sets.
With your reply, I see that you think that forcing breakage will let you
help those who want to drop support now. That's fine. It wasn't clear in
your earlier mail that you were ponying up resource to help people get over
any python2-dropping hurdles and that you fear they won't come to you with
those problems until you force the issue on them.
-Toshio
1:39 p.m.
On 03/23/18 18:41, Toshio Kuratomi wrote:
On Fri, Mar 23, 2018, 9:50 AM Petr Viktorin <pviktori(a)redhat.com
<mailto:pviktori@redhat.com>> wrote:
On 03/23/18 16:43, Toshio Kuratomi wrote:
>
>
> On Fri, Mar 23, 2018, 8:13 AM Petr Viktorin <pviktori(a)redhat.com
<mailto:pviktori@redhat.com>
> <mailto:pviktori@redhat.com <mailto:pviktori@redhat.com>>>
wrote:
>
> On 03/23/18 15:15, Toshio Kuratomi wrote:
> > Something that occurred to me last night, rather than a
> conditional on
> > Fedora version, is there a macro that we could provide to mean
> python2
> > is available in this Fedora version? That way packagers
wanting to
> > support their packages on the versions of python that the
> platform ships
> > can conditionalize on that imstead of fedora release (which is
> variable
> > depending on whether someone picked up and drops support
for the
> > orphaned python 2 package)
>
> I'm not sure how useful that would be. Wouldn't we want that
not only
> for the python2 package, but also for other dependencies?
> Django's py2 subpackage is dropped already. Should there have
been a
> macro advertising that?
>
>
> Also, we want to *avoid* breaking everything at once.
Providing a flag
> that gets flipped at one moment wouldn't solve much.
> _______________________________________________
>
> Depends on what the groups of packagers want... A macro for
Django would
> definitely have given an easy option for packagers to take advantage
> of. Otoh, how far in advance was the Django removal telegraphed
and how
> much chance was there that a new maintainer would pick it up?
Um, Django set its current policy back in 2015 (see
https://www.djangoproject.com/weblog/2015/jun/25/roadmap/
<https://www.djangoproject.com/weblog/2015/jun/25/roadmap/>):
We will support a Python version up to and including the
first Django LTS release whose security support ends after
security support for that version of Python ends. For
example, Python 3.3 security support ends September 2017 and
Django 1.8 LTS security support ends April 2018. Therefore
Django 1.8 is the last version to support Python 3.3.
Fedora follows upstream, packaging the newest version (which is now
incompatible with py2). And the django-1.11 LTS release is packaged in
Fedora for Python 2, as a courtesy to projects that need a bit more
time.
(Of course, instead of maintaining the LTS I could just say to kobo or
pulp that they're out of time and on their own. That's not what I want.
But I also don't want to maintain the LTS forever.)
> It doesn't do as much good for a package that is going to
definitely drop
> support in the very next release as it does for a package that is
going
> to drop support two releases from now, maybe, unless someone
decides to
> pick it up, even at the last minute, perhaps only after they realize
> it's been removed from the repository....
Python 2 is security-critical software with thousands of dependencies.
If someone is not following along, and wakes up at the last minute to
maintain it, then I *still* want to remove as many of those dependencies
as possible -- both to make their job easier, and because I wouldn't
trust them to do a very good job.
> Why do we want to avoid *breaking* everything at once? I can see us
> wanting to keep things *working* as long as it makes sense to the
set of
> packagers that care (which I think adding the macro would aid in)
but it
> doesn't feel like actively designing things to break a little at
a time
> is helpful to anyone.
I *don't* want to support Python 2. I *do* want to give packagers a
more-than-fair change to switch to py3-only, if they haven't done so
yet. And possibly help with concrete problems they'll have when
switching.
But I can't help with those problems if they appear all at once.
Python2 is used in many parts of Fedora (and beyond) that we don't *see*
until we start removing things -- build tools, infrastructure, who knows
what else. Removing these things lets us react to problems as they
come up.
If everyone starts dropping the py2 subpackages *now*, starting from the
leaves, then by circa 2020 we can orphan Python 2 with clean conscience.
> Users can't count on things working from release
> to release and packagers have to do more work to keep the pieces they
> care about working.
Sorry, but with that mindset I could just orphan Python 2 now. That
would be irresponsible.
You're only reading half of what I wrote above. I was saying that it
doesn't help either those who want to keep it or those who want to drop
it. Inconsistency hurts both of those sets of people. Dropping now
would help one for the detriment of the other set. Dropping at once in
the future would be a compromise to those two sets.
Ah, but I don't see those two sets of people -- those who *want to* drop
py2 versus those who *don't want to*.
If *anyone* would be in the latter group -- they don't want to drop py2,
and so they are willing to put in the work to support it -- then all
this is moot: the current py2 maintainers will celebrate, give python2
to that someone else, and go work on more interesting things.
Instead, there are people who *can* drop py2 from their packages and
those who *can't*.
If you (or your upstream) are working to drop Python 2 and need three
more years for it, that's sad, but OK! you still have to do the work
(because we, sadly, can't help everyone), but we don't want to leave you
hanging if you're trying.
But if you're *asking* when to remove Python 2 support, the answer is
clear. No need for a macro to give the signal. Drop py2 now, or if you
maintain a single spec for all Fedoras, conditionalize on Fedora > 28.
If you want to maintain py2 subpackages for "as long as possible", there
will come a point in time when you will need to decide either to drop
py2, or take over maintenance of Python 2 itself. As above, we
celebrate, and leave you to it.
That's not a threat though -- we'd much rather communicate, advise and help.
With your reply, I see that you think that forcing breakage will let
you
help those who want to drop support now. That's fine. It wasn't clear
in your earlier mail that you were ponying up resource to help people
get over any python2-dropping hurdles and that you fear they won't come
to you with those problems until you force the issue on them.
Sorry! Too many nuances to this, I'm afraid. It's hard to express
everything, especially in a way to make those who just skim the text to
get the right idea.
2219
days inactive
2220
days old
python-devel@lists.fedoraproject.org
9 comments
4 participants
participants (4)
-
John Dulaney -
Miro Hrončok -
Petr Viktorin -
Toshio Kuratomi