On 03/24/18 15:28, Kevin Kofler wrote:
Petr Viktorin wrote:
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
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
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 -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
