Re: Intent to orphan Python 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux