On Mon, 26 Mar 2018, 10:59 Petr Viktorin, <pviktori@xxxxxxxxxx> wrote:
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
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.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
