Re: Intent to orphan Python 2

[Kevin Fenzi]

On 07/17/2018 04:35 PM, Miro Hrončok wrote:
...snip...
> 
> 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




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/WSXR3MHI3G3TFE34LBKTVZF6VLFHTYJG/

Re: Intent to orphan Python 2

[Nico Kadel-Garcia]

On Tue, Jul 17, 2018 at 1:43 PM, Miro Hrončok  wrote:
> On 17.7.2018 14:16, Nico Kadel-Garcia wrote:
>>
>> On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis
>>  wrote:
>>>
>>>
>>>
>>> - Original Message -
>>>>
>>>> From: "R P Herrold" 
>>>> To: "Development discussions related to Fedora"
>>>> 
>>>> Sent: Monday, July 16, 2018 8:57:11 PM
>>>> Subject: Re: Intent to orphan Python 2
>>>>
>>>> On Mon, 16 Jul 2018, Miro Hrončok wrote:
>>>>
>>>>> On 23.3.2018 12:23, Petr Viktorin wrote:
>>>>>>
>>>>>> 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
>>>>
>>>>>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/ABYLVXBWCMERLSXOUCORT5L5JR3ZWNEU/

Re: Intent to orphan Python 2

[Miro Hrončok]

On 18.7.2018 00:03, Kevin Fenzi wrote:

On 07/16/2018 11:15 AM, Miro Hrončok wrote:


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).



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.



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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/AZX2L65LO4W75GAXIAFE7IDOOGCWFMPX/

Re: Intent to orphan Python 2

[Kevin Fenzi]

On 07/16/2018 11:15 AM, Miro Hrončok wrote:

> 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?

> 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





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/W46PNNICWCFUPPLBRBZNQF2MDJ2PKVMF/

Re: Intent to orphan Python 2

[Miro Hrončok]

On 17.7.2018 14:16, Nico Kadel-Garcia wrote:

On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis
 wrote:



- Original Message -

From: "R P Herrold" 
To: "Development discussions related to Fedora" 
Sent: Monday, July 16, 2018 8:57:11 PM
Subject: Re: Intent to orphan Python 2

On Mon, 16 Jul 2018, Miro Hrončok wrote:


On 23.3.2018 12:23, Petr Viktorin wrote:

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


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.



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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/N772E3ATIRLKIFR6ZIA7CAU6PA6YVTFK/

Re: Intent to orphan Python 2

[Nico Kadel-Garcia]

On Mon, Jul 16, 2018 at 6:18 PM, Charalampos Stratakis
 wrote:
>
>
> - Original Message -
>> From: "R P Herrold" 
>> To: "Development discussions related to Fedora" 
>> 
>> Sent: Monday, July 16, 2018 8:57:11 PM
>> Subject: Re: Intent to orphan Python 2
>>
>> On Mon, 16 Jul 2018, Miro Hrončok wrote:
>>
>> > On 23.3.2018 12:23, Petr Viktorin wrote:
>> > > 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
>>
>> > > 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.

>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/B6JMDJXD44BF3I7J5WKOTYRXYBJKVNXP/

Re: Intent to orphan Python 2

[Charalampos Stratakis]

- Original Message -
> From: "R P Herrold" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Monday, July 16, 2018 8:57:11 PM
> Subject: Re: Intent to orphan Python 2
> 
> On Mon, 16 Jul 2018, Miro Hrončok wrote:
> 
> > On 23.3.2018 12:23, Petr Viktorin wrote:
> > > 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
> 
> > > 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/V6TXSNJ7ER4SBK2D6L4BWU7YLLARJE7T/
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/DAHZTVERHGRCASAXAL5UOBXJQE5SDSLR/

Re: Intent to orphan Python 2

[R P Herrold]

On Mon, 16 Jul 2018, Miro Hrončok wrote:

> On 23.3.2018 12:23, Petr Viktorin wrote:
> > 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

> > 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/V6TXSNJ7ER4SBK2D6L4BWU7YLLARJE7T/

Re: Intent to orphan Python 2

[Miro Hrončok]

On 23.3.2018 12:23, Petr Viktorin wrote:

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/


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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/2ELVUFQ22YUG5XGQZJGELO7YSCMPRRGD/

Re: Intent to orphan Python 2

[Petr Viktorin]

On 04/08/18 17:49, Kevin Kofler wrote:

Rex Dieter wrote:

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Zbigniew Jędrzejewski-Szmek]

On Mon, Apr 09, 2018 at 12:55:04AM -0500, Jason L Tibbitts III wrote:
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> 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.)

> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Jason L Tibbitts III]

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Nico Kadel-Garcia]

On Sun, Apr 8, 2018 at 11:49 AM, Kevin Kofler  wrote:
> Rex Dieter wrote:
>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Kofler]

Rex Dieter wrote:
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Rex Dieter]

Kevin Kofler wrote:

> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Kofler]

Peter Oliver wrote:
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Peter Oliver]

On Sat, 7 Apr 2018, 19:17 Miro Hrončok,  wrote:

Strong reasons for the distribution were already discussed above, including:
>
>   * 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
> 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

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Fenzi]

On 04/06/2018 02:18 AM, Petr Viktorin wrote:

> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Fenzi]

On 04/05/2018 05:10 PM, Eric Garver wrote:

...snip...

> 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.

> Alternatively you can install python3-ansible.

Well, that will cause the host side to use python3, but not the target.

> 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.

> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 7.4.2018 18:45, Kevin Kofler wrote> How about just NOT removing the 
subpackage to begin with if there is no

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Adam Williamson]

On Fri, 2018-04-06 at 11:09 +0100, James Hogarth wrote:
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Kofler]

Miro Hrončok wrote:
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 07, 2018 at 04:15:15PM +0200, Miro Hrončok wrote:
> On 7.4.2018 15:53, Zbigniew Jędrzejewski-Szmek wrote:
> >On Fri, Apr 06, 2018 at 10:33:04AM -0500, Jason L Tibbitts III wrote:
> >>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
and a package being retired. Those rules say [1]:
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 7.4.2018 15:53, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Apr 06, 2018 at 10:33:04AM -0500, Jason L Tibbitts III wrote:

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 06, 2018 at 10:33:04AM -0500, Jason L Tibbitts III wrote:
> 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?).

>  If PackagerA wants to drop python2, but PackagerB wants to
> volunteer to maintain it, the only options I see are:

> * 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.

> * 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 06, 2018 at 11:18:13AM +0200, Petr Viktorin wrote:
> On 04/04/18 18:21, James Hogarth wrote:
> [...]
> >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.
> 
> >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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Jason L Tibbitts III]

> "CS" == Charalampos Stratakis  writes:

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Charalampos Stratakis]

- Original Message -
> From: "James Hogarth" <james.hoga...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Friday, April 6, 2018 12:09:10 PM
> Subject: Re: Intent to orphan Python 2
> 
> On 6 April 2018 at 10:18, Petr Viktorin <pvikt...@redhat.com> wrote:
> > On 04/04/18 18:21, James Hogarth wrote:
> > [...]
> >>
> >> 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.
> 
> >> 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.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On 6 April 2018 at 10:18, Petr Viktorin  wrote:
> On 04/04/18 18:21, James Hogarth wrote:
> [...]
>>
>> 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.

>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On 6 April 2018 at 01:10, Eric Garver  wrote:
> On Thu, Apr 05, 2018 at 10:53:03PM +0200, Fabio Valentini wrote:
>> On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth  
>> wrote:
>> >
>> >
>> > On Thu, 5 Apr 2018, 18:28 Matthew Miller,  wrote:
>> >>
>> >> On Thu, Apr 05, 2018 at 04:03:24PM +, James Hogarth wrote:
>> >> > > 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
>> >> ___
>> >> devel mailing list -- devel@lists.fedoraproject.org
>> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> >
>> >
>> > 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
>
> 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.
>
>> - the change was explicitly about f29+ (and not f28, too).
>
> I had dropped the python2-firewall subpackage before this thread was
> started.
>
>>
>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 04/04/18 18:21, James Hogarth wrote:
[...]

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.


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.


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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Charalampos Stratakis]

- Original Message -
> From: "Fabio Valentini" <decatho...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Thursday, April 5, 2018 10:53:03 PM
> Subject: Re: Intent to orphan Python 2
> 
> On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth <james.hoga...@gmail.com>
> wrote:
> >
> >
> > On Thu, 5 Apr 2018, 18:28 Matthew Miller, <mat...@fedoraproject.org> wrote:
> >>
> >> On Thu, Apr 05, 2018 at 04:03:24PM +, James Hogarth wrote:
> >> > > 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
> >> <mat...@fedoraproject.org>
> >> Fedora Project Leader
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
> >
> > 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.
> 

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
> 
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Eric Garver]

On Thu, Apr 05, 2018 at 10:53:03PM +0200, Fabio Valentini wrote:
> On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth  wrote:
> >
> >
> > On Thu, 5 Apr 2018, 18:28 Matthew Miller,  wrote:
> >>
> >> On Thu, Apr 05, 2018 at 04:03:24PM +, James Hogarth wrote:
> >> > > 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
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
> >
> > 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

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.

> - the change was explicitly about f29+ (and not f28, too).

I had dropped the python2-firewall subpackage before this thread was
started.

> 
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Fabio Valentini]

On Thu, Apr 5, 2018 at 9:06 PM, James Hogarth  wrote:
>
>
> On Thu, 5 Apr 2018, 18:28 Matthew Miller,  wrote:
>>
>> On Thu, Apr 05, 2018 at 04:03:24PM +, James Hogarth wrote:
>> > > 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
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
> 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

>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On Thu, 5 Apr 2018, 18:28 Matthew Miller,  wrote:

> On Thu, Apr 05, 2018 at 04:03:24PM +, James Hogarth wrote:
> > > 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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 ;)


>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Matthew Miller]

On Thu, Apr 05, 2018 at 04:03:24PM +, James Hogarth wrote:
> > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On Thu, 5 Apr 2018, 16:05 Matthew Miller,  wrote:

> On Thu, Apr 05, 2018 at 03:11:47PM +0100, James Hogarth wrote:
> > 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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Matthew Miller]

On Thu, Apr 05, 2018 at 03:11:47PM +0100, James Hogarth wrote:
> 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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On 5 April 2018 at 13:23, Matthew Miller  wrote:
> On Mon, Mar 26, 2018 at 11:58:57AM +0200, Petr Viktorin wrote:
>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Matthew Miller]

On Mon, Mar 26, 2018 at 11:58:57AM +0200, Petr Viktorin wrote:
> 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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On 4 April 2018 at 22:06, Kevin Fenzi  wrote:
> On 04/04/2018 01:35 PM, James Hogarth wrote:
>> On Wed, 4 Apr 2018, 21:28 Adam Williamson, 
>> wrote:
>>
>>> 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=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 ...

>> 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.

>> 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 -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Fenzi]

On 04/04/2018 01:35 PM, James Hogarth wrote:
> On Wed, 4 Apr 2018, 21:28 Adam Williamson, 
> wrote:
> 
>> 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=is%3Aissue+is%3Aopen+label%3Apython3+label%3Abug

> 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.

> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Bill Nottingham]

Adam Williamson (adamw...@fedoraproject.org) said: 
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On Wed, 4 Apr 2018, 21:28 Adam Williamson, 
wrote:

> On Wed, 2018-04-04 at 10:51 -0700, Kevin Fenzi wrote:
> > On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
> > > On 04/04/2018 09:21 AM, James Hogarth wrote:
> > >
> > > ...snip...
> > >
> > > > 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)
>
> 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 -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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.

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On Wed, 4 Apr 2018, 18:52 Kevin Fenzi,  wrote:

> On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
> > On 04/04/2018 09:21 AM, James Hogarth wrote:
> >
> > ...snip...
> >
> >> 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 -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Adam Williamson]

On Wed, 2018-04-04 at 10:51 -0700, Kevin Fenzi wrote:
> On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
> > On 04/04/2018 09:21 AM, James Hogarth wrote:
> > 
> > ...snip...
> > 
> > > 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)

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Fenzi]

On 04/04/2018 10:46 AM, Kevin Fenzi wrote:
> On 04/04/2018 09:21 AM, James Hogarth wrote:
> 
> ...snip...
> 
>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Fenzi]

On 04/04/2018 09:21 AM, James Hogarth wrote:

...snip...

> 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'

> 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.

> 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. :(
> 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.

> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[James Hogarth]

On Mon, 26 Mar 2018, 10:59 Petr Viktorin,  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@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org


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 -- 

Re: Intent to orphan Python 2

[Petr Viktorin]

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

OT: Re: Intent to orphan Python 2

[stan]

> > On Sat, Mar 24, 2018 at 08:56:02PM +0100, Matěj Cepl wrote:

> On Sat, 24 Mar 2018 23:12:31 +
> "Richard W.M. Jones"  wrote:

> > 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 25.3.2018 14:25, Kevin Kofler wrote:

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Kofler]

Silvia Sánchez wrote:
> 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.

> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Silvia Sánchez]

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


On 24 March 2018 at 23:12, Richard W.M. Jones  wrote:

> On Sat, Mar 24, 2018 at 08:56:02PM +0100, Matěj Cepl wrote:
> > On 2018-03-24, 15:09 GMT, Richard W.M. Jones wrote:
> > > 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 -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Richard W.M. Jones]

On Sat, Mar 24, 2018 at 08:56:02PM +0100, Matěj Cepl wrote:
> On 2018-03-24, 15:09 GMT, Richard W.M. Jones wrote:
> > 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Matěj Cepl]

On 2018-03-24, 15:09 GMT, Richard W.M. Jones wrote:
> 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: mc...@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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Richard W.M. Jones]

On Fri, Mar 23, 2018 at 04:07:51PM +0100, Ralf Corsepius wrote:
> On 03/23/2018 12:23 PM, Petr Viktorin wrote:
> >tl;dr: Unless someone steps up to maintain Python 2 after 2020, we
> >need to start dropping python2 packages now.
> Bummer - I am speechless.
> 
> >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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Kevin Kofler]

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.

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Gerald Henriksen]

On Fri, 23 Mar 2018 12:57:19 -0400, you wrote:

>On 03/23/2018 07:23 AM, Petr Viktorin wrote:
>> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/23/18 17:57, Randy Barlow wrote:

On 03/23/2018 07:23 AM, Petr Viktorin wrote:

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?


I'm afraid we won't be able to handle the massive breakage in random 
build scripts, infrastructure, and (especially) areas we don't yet know 
will break. The likely outcome of such a flag day would be that the 
change would need to be reverted immediately. (You're welcome to try 
this locally. The problems start with the buildroot broken in ways I 
didn't know could exist, and continue from there.)
Even if the base distro would end up usable, we wouldn't be able to help 
all the non-"essential" packages if all problems appear at once.


Instead we want to start with the things we *know* can be dropped, and 
work on getting more things into that state. That should bring a steady 
stream of problems, which can be tackled one by one.

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Randy Barlow]

On 03/23/2018 07:23 AM, Petr Viktorin wrote:
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 23.3.2018 15:16, Jerry James wrote:

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  - 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.


Exactly. You can check if your package is a leaf at [1].

[1] http://fedora.portingdb.xyz/#legacy-leaf


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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Randy Barlow]

On 03/23/2018 11:07 AM, Ralf Corsepius wrote:
> 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Ralf Corsepius]

On 03/23/2018 12:23 PM, Petr Viktorin wrote:
tl;dr: Unless someone steps up to maintain Python 2 after 2020, we need 
to start dropping python2 packages now.

Bummer - I am speechless.

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Jerry James]

On Fri, Mar 23, 2018 at 7:29 AM, Matěj Cepl  wrote:
> 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  - 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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Matěj Cepl]

On 2018-03-23, 11:23 GMT, Petr Viktorin wrote:
> 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: mc...@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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/20/18 21:47, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Mar 20, 2018 at 04:11:46PM +, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Mar 20, 2018 at 03:28:23PM +0100, Miro Hrončok wrote:

On 20.3.2018 14:45, Zbigniew Jędrzejewski-Szmek wrote:

Indeed, I'm using those python packages like a dinosaur ;)


:D


What about adding conditionals like

%if 0%{?rhel} > 7 || 0%{?fedora} > 31
# Disable python2 build by default
%bcond_with python2
%else
%bcond_without python2
%endif

starting now?


I am not against that. However currently that number (31) is
somewhat artificial. it's up to the maintainer to choose if it's 28
or 32 (or anything in between). Should we somehow recommend a
specific Fedora release here? Why 31?

Re 31: my thinking was that python2-eos is at 2010-01-01. If we keep
up current biannual release schedule, we'll have 28 and 29 this year,
30 and 31 in 2019, and 32 in early 2020. But this is of course wrong,
because we need python2 support for the lifetime of the release, not
just at the start. So actually 29 which will be supported until
2018-10-30 + 13 months ≈ 2020-01-01, is the last release overlapped
by python2 support. This right conditional would be:

%if 0%{?rhel} > 7 || 0%{?fedora} > 28

but that round around the corner. So it's not even necessary to add
the conditional, as long as the patch to drop support is only added
in rawhide, not F28.

OK, so I withdraw my objections. Removing python2 support in rawhide
is fine.


Pff, sorry I can't count. The right conditional would be
   %if 0%{?rhel} > 7 || 0%{?fedora} > 29
so dropping support in rawhide right now would be premature. It seems
that adding a conditional like that is the way to go for now.



Compared to just removing the subpackage, it's a difference of just one 
release. It may not be worth the complication of conditionalizing 
everything.


I'd say maintainers can either drop the subpackages now in Rawhide, or 
add a conditional for Fedora > 29 -- up to the maintainer.

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 20, 2018 at 04:11:46PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 20, 2018 at 03:28:23PM +0100, Miro Hrončok wrote:
> > On 20.3.2018 14:45, Zbigniew Jędrzejewski-Szmek wrote:
> > >Indeed, I'm using those python packages like a dinosaur ;)
> > 
> > :D
> > 
> > >What about adding conditionals like
> > >
> > >%if 0%{?rhel} > 7 || 0%{?fedora} > 31
> > ># Disable python2 build by default
> > >%bcond_with python2
> > >%else
> > >%bcond_without python2
> > >%endif
> > >
> > >starting now?
> > 
> > I am not against that. However currently that number (31) is
> > somewhat artificial. it's up to the maintainer to choose if it's 28
> > or 32 (or anything in between). Should we somehow recommend a
> > specific Fedora release here? Why 31?
> Re 31: my thinking was that python2-eos is at 2010-01-01. If we keep
> up current biannual release schedule, we'll have 28 and 29 this year,
> 30 and 31 in 2019, and 32 in early 2020. But this is of course wrong,
> because we need python2 support for the lifetime of the release, not
> just at the start. So actually 29 which will be supported until
> 2018-10-30 + 13 months ≈ 2020-01-01, is the last release overlapped
> by python2 support. This right conditional would be:
> 
> %if 0%{?rhel} > 7 || 0%{?fedora} > 28
> 
> but that round around the corner. So it's not even necessary to add
> the conditional, as long as the patch to drop support is only added
> in rawhide, not F28.
> 
> OK, so I withdraw my objections. Removing python2 support in rawhide
> is fine.

Pff, sorry I can't count. The right conditional would be
  %if 0%{?rhel} > 7 || 0%{?fedora} > 29
so dropping support in rawhide right now would be premature. It seems
that adding a conditional like that is the way to go for now.

> > Should a Fedora Change for that release be crafted that says "Mass
> > python2 packages removal"?
> 
> Yeah, I think it should be filed as a F29 change.

F30 might be more appropriate.

Zbyszek
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 20.3.2018 17:11, Zbigniew Jędrzejewski-Szmek wrote:

Should a Fedora Change for that release be crafted that says "Mass
python2 packages removal"?


Yeah, I think it should be filed as a F29 change.


I think we should send the e-mail first and do that after, if nobody 
takes python2.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 20, 2018 at 03:28:23PM +0100, Miro Hrončok wrote:
> On 20.3.2018 14:45, Zbigniew Jędrzejewski-Szmek wrote:
> >Indeed, I'm using those python packages like a dinosaur ;)
> 
> :D
> 
> >What about adding conditionals like
> >
> >%if 0%{?rhel} > 7 || 0%{?fedora} > 31
> ># Disable python2 build by default
> >%bcond_with python2
> >%else
> >%bcond_without python2
> >%endif
> >
> >starting now?
> 
> I am not against that. However currently that number (31) is
> somewhat artificial. it's up to the maintainer to choose if it's 28
> or 32 (or anything in between). Should we somehow recommend a
> specific Fedora release here? Why 31?
Re 31: my thinking was that python2-eos is at 2010-01-01. If we keep
up current biannual release schedule, we'll have 28 and 29 this year,
30 and 31 in 2019, and 32 in early 2020. But this is of course wrong,
because we need python2 support for the lifetime of the release, not
just at the start. So actually 29 which will be supported until
2018-10-30 + 13 months ≈ 2020-01-01, is the last release overlapped
by python2 support. This right conditional would be:

%if 0%{?rhel} > 7 || 0%{?fedora} > 28

but that round around the corner. So it's not even necessary to add
the conditional, as long as the patch to drop support is only added
in rawhide, not F28.

OK, so I withdraw my objections. Removing python2 support in rawhide
is fine.

> Should a Fedora Change for that release be crafted that says "Mass
> python2 packages removal"?

Yeah, I think it should be filed as a F29 change.

Zbyszek
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Petr Viktorin]

On 03/20/18 14:45, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Mar 20, 2018 at 12:23:06PM +0100, Miro Hrončok wrote:

On 20.3.2018 11:25, Zbigniew Jędrzejewski-Szmek wrote:

to push the whole ecosystem. The proposed model of nipping python2 support
at the edges is the same thing, in reverse. First some leaf packages
are dropped, and then some somewhat more important packages, and then
suddenly it becomes hard to use python2 for anything "serious", even
though it's still "available". I think that's a bad way to proceed for
our users. Let them have a single moment where python2 support goes away.
Announce this moment at least a year in advance. Let them keep running
the last release before that for as long as they need.


I think there is a fundamental difference of how I see python RPMs
in Fedora and how you do. In my POV, purpose of pythonX-foo packages
that only bring libraries is to provide dependency for an
application that happens to be written in python, runs on pythonX
and need the foo library. If there is no such application packaged
in Fedora, I see no purpose of such package. (Except maybe if such
app is packaged in another repository used by our users. That's a
corner case and if the maintainer of pythonX-foo is aware of that,
it can always be used as argument to keep pythonX-foo.)


Indeed, I'm using those python packages like a dinosaur ;)
But more seriously, I think the distinction between library and app in
the python world is neither clear nor particularly significant. Distro
packaging provides clear benefits in both cases: easy and quick
install, easy and quick uninstall, testing, provenance history,
license checks, general reliability.

So instead of losing packages, I'd like to see more automatic
packaging and updates of packages from pypi and other "forges".
We are making steps in that direction, but not quickly enough.


We live in an era of pip (and rubygems, and cpan, and npm etc.).
Trying to mirror those systems with RPM packages just because it's
possible is tedious, incomplete and mostly pointless IMHO. An era
when upstream projects were eager to get their tool into the distros
has passed. Having pythonX-foo packaged where no other
tool/app/service needs it is not beneficial (if foo is a library
only thing, not a tool itself). I have this opinion even with
python3 packages.

Developers who wants to use python2 for whatever reasons (rational
or emotional ones) can do that on Fedora. We encourage developers to
use virtual environments and pip [1]. Removing leaf python2 packages
does not block them here at all.


Let them have a single moment where python2 support goes away.


Removing all python2 things at one point is impossible. We've tried
to test this with Django [2] on a much smaller scale. (Tens instead
of thousands packages.) It took us too much time and too much
energy. At the end, too much packages were just retired because
their maintainers are "dead". I cannot imagine doing this on current
scale in 2020.
We can just retire python2 then and see what breaks. Honestly,
everything would break.

I don't think this is entirely comparable. Django20 was about updating
packages and switching support from python2 to python3. Just dropping
existing support for python2 is something much easier.


Maybe it's much easier, but it's still not trivial.

I just saw a package that uses epydoc to generate its documentation, 
from its py2 code. Since epydoc is not ported, that package would lose 
its documentation if python2 was just suddenly dropped – and we wouldn't 
know in advance, because the package was in the "dual py2/py3 support" 
bucket.
But I'm not complaining about epydoc in general. I'm afraid there are 
many more cases like that – cases where we won't know about the problem 
until we try to remove the py2 packages. Especially those with 
unresponsive maintainers, which tend to use the most interesting ancient 
technology.


I don't see a good way to uncover such problems other than to start 
removing stuff.




Nevertheless, I agree that this still is a very significant chunk of
work at this scale. So spreading this out makes a lot of sense, but
imho python2 subpackages don't need to go away, they can just be
conditionalized.

What about adding conditionals like

%if 0%{?rhel} > 7 || 0%{?fedora} > 31
# Disable python2 build by default
%bcond_with python2
%else
%bcond_without python2
%endif

starting now?


Agreed, we just need to bikeshed the "31" number there.

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 20.3.2018 14:45, Zbigniew Jędrzejewski-Szmek wrote:

Indeed, I'm using those python packages like a dinosaur ;)


:D


What about adding conditionals like

%if 0%{?rhel} > 7 || 0%{?fedora} > 31
# Disable python2 build by default
%bcond_with python2
%else
%bcond_without python2
%endif

starting now?


I am not against that. However currently that number (31) is somewhat 
artificial. it's up to the maintainer to choose if it's 28 or 32 (or 
anything in between). Should we somehow recommend a specific Fedora 
release here? Why 31?


Should a Fedora Change for that release be crafted that says "Mass 
python2 packages removal"?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Miro Hrončok]

On 20.3.2018 11:25, Zbigniew Jędrzejewski-Szmek wrote:

to push the whole ecosystem. The proposed model of nipping python2 support
at the edges is the same thing, in reverse. First some leaf packages
are dropped, and then some somewhat more important packages, and then
suddenly it becomes hard to use python2 for anything "serious", even
though it's still "available". I think that's a bad way to proceed for
our users. Let them have a single moment where python2 support goes away.
Announce this moment at least a year in advance. Let them keep running
the last release before that for as long as they need.


I think there is a fundamental difference of how I see python RPMs in 
Fedora and how you do. In my POV, purpose of pythonX-foo packages that 
only bring libraries is to provide dependency for an application that 
happens to be written in python, runs on pythonX and need the foo 
library. If there is no such application packaged in Fedora, I see no 
purpose of such package. (Except maybe if such app is packaged in 
another repository used by our users. That's a corner case and if the 
maintainer of pythonX-foo is aware of that, it can always be used as 
argument to keep pythonX-foo.)


We live in an era of pip (and rubygems, and cpan, and npm etc.).
Trying to mirror those systems with RPM packages just because it's 
possible is tedious, incomplete and mostly pointless IMHO. An era when 
upstream projects were eager to get their tool into the distros has 
passed. Having pythonX-foo packaged where no other tool/app/service 
needs it is not beneficial (if foo is a library only thing, not a tool 
itself). I have this opinion even with python3 packages.


Developers who wants to use python2 for whatever reasons (rational or 
emotional ones) can do that on Fedora. We encourage developers to use 
virtual environments and pip [1]. Removing leaf python2 packages does 
not block them here at all.


> Let them have a single moment where python2 support goes away.

Removing all python2 things at one point is impossible. We've tried to 
test this with Django [2] on a much smaller scale. (Tens instead of 
thousands packages.) It took us too much time and too much energy. At 
the end, too much packages were just retired because their maintainers 
are "dead". I cannot imagine doing this on current scale in 2020.
We can just retire python2 then and see what breaks. Honestly, 
everything would break.


We need to communicate loudly that Python 2 is dead. And this is a way 
to do it. If the maintainrs add conditionals for Fedora 33, let them 
have it. But every single python2 package that goes away is a good thing 
longterm both for Fedora and for the Python ecosystem.



> If we want to prepare for the python2-eol, IMHO we should first finish
> all the steps that don't impact users: convert our tooling, make sure
> python2 is not used in build for anything where python3 can be used,
> rename packages, fix provides and requires, update she-bangs, add
> conditionals to make dropping python2 support easy. In particular,
> let's first finish Changes/Avoid_usr_bin_python_in_RPM_Build.

Yes, we should focus on that. But if we don't do things in parallel, we 
have very little chance to move forward fast enough.



[1] 
https://developer.fedoraproject.org/tech/languages/python/python-installation.html

[2] https://fedoraproject.org/wiki/Changes/Django20

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Intent to orphan Python 2

[Zbigniew Jędrzejewski-Szmek]

On Tue, Mar 20, 2018 at 10:51:30AM +0100, Petr Viktorin wrote:
> Hello,
> Here is a message I want to post to devel-announce later. Let me
> know if you see anything wrong (or would like to take over python2
> maintainership).
> 
> ---
> Intent to orphan Python 2
First a disclaimer: I'm all for moving to python3, so I'm not
disagreeing with the general idea, but with the transition plan.

> tl;dr: Unless someone steps up to Python 2 after 2020, we need to
> start dropping python2 packages now.
I think this is a contentious statement. "need" is the wrong word.
"One of the ways to prepare for the declared EOS from upsteam is to"
would be more accurate.

And it's just one of the possible ways. Another would be prepare a
conditional in all spec files and simply flip it over before a mass
rebuild for F32 (or whatever).

> 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.
This is also misleading. Those 3000 packages have different upstreams,
and many of those upstreams will support python2 even after python-eol.

> 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".

The way you propose is essentially a mirror of how python3 support
was introduced. For a long time it was hard to use python3 for anything
serious because there was _always_ one or two more unported dependencies.
It took many years to reach this critical mass where everything
"important" was available. This period was harsh on users, because python3
was nice and shiny but people were unable to switch and unable to
_influence_ this state in any significant way, the way that it is hard
to push the whole ecosystem. The proposed model of nipping python2 support
at the edges is the same thing, in reverse. First some leaf packages
are dropped, and then some somewhat more important packages, and then
suddenly it becomes hard to use python2 for anything "serious", even
though it's still "available". I think that's a bad way to proceed for
our users. Let them have a single moment where python2 support goes away.
Announce this moment at least a year in advance. Let them keep running
the last release before that for as long as they need.

If we want to prepare for the python2-eol, IMHO we should first finish
all the steps that don't impact users: convert our tooling, make sure
python2 is not used in build for anything where python3 can be used,
rename packages, fix provides and requires, update she-bangs, add
conditionals to make dropping python2 support easy. In particular,
let's first finish Changes/Avoid_usr_bin_python_in_RPM_Build [1].

[1] https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build

Zbyszek
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org