Hello Fedora Council.
My name is Abdel Martinez (fas:potty), from Panama and contributor of Fedora Project for 5 years.
There is a change [0] that propose the implementation of Python 3 as the default for Fedora 23. I think this change is one of the most important for Fedora. It is a difficult task that, in my opinion, that could not be achieved by a small group of developers.
As member of the community, I propose a Fedora Activity Day on November 14-15 to help out reducing the list of still-non-ported Python packages.
I emailed with Matej Stuchlik (copied on this loop), who has been very cooperative helping me out identifying the list of packages that have not been ported to Python 3.
We discussed the possibility of making this FAD, global, having simultaneous events on NA, EMEA, LATAM and APAC. Right now we have only point-of-contacts in LATAM (me) and EMEA (Matej).
In relation to EMEA, Matej told me about participating on PyCon CZ [2] as a workshop. Maybe he could tell you more about it.
Regarding LATAM, I have an estimated budget of $3,000. This includes transportation, accommodation and food (items listed in the wiki "How to organize a FAD" [1]). Also we have the plan (list of packages) and participants (right now are 6 members).
Hope you like the idea. Thanks in advance for reading this.
Kindest regards!
[0] https://fedoraproject.org/wiki/Changes/Python_3_as_Default [1] https://fedoraproject.org/wiki/How_to_organize_a_FAD [2] http://cz.pycon.org
On Fri, Sep 25, 2015 at 10:53:11AM -0500, Abdel G. Martínez L. wrote:
We discussed the possibility of making this FAD, global, having simultaneous events on NA, EMEA, LATAM and APAC. Right now we have only point-of-contacts in LATAM (me) and EMEA (Matej).
Especially in light of that,iIs there a lot of value in having this be an in-person FAD rather than a "virtual FAD", conducted online?
Also, while I like Python, I'm having trouble seeing this as really highly important for Fedora. It obviously fits with our "first" value, but I don't see a gigantic strategic win. I mean, advancing version numbers happens all the time. Can you elaborate more on the high-level impact expected from this?
El 2015-09-26 11:50, Matthew Miller escribió:
On Fri, Sep 25, 2015 at 10:53:11AM -0500, Abdel G. Martínez L. wrote:
We discussed the possibility of making this FAD, global, having simultaneous events on NA, EMEA, LATAM and APAC. Right now we have only point-of-contacts in LATAM (me) and EMEA (Matej).
Especially in light of that,iIs there a lot of value in having this be an in-person FAD rather than a "virtual FAD", conducted online?
From my point of view, Brno has most of the people (if not all) working on this porting. So, having some face to face time to engage in this initiative outside Brno will help distribute the load to other palces. This will facilitating future FADs on this topic, those can be done regionally with online support form Brno.
Also, while I like Python, I'm having trouble seeing this as really highly important for Fedora. It obviously fits with our "first" value, but I don't see a gigantic strategic win. I mean, advancing version numbers happens all the time. Can you elaborate more on the high-level impact expected from this?
The only PyCon that I have been was in 2011 and everybody was saying something along the lines of: "Python 3 is okey if they don't touch my stuff". Despite the time passed, Python 3 is not the default version. I think if advancing version number in Python is going to happen, needs some championship to make it happen (the "first" value). The number of packages having double version is increasing. The burden to maintain those duplicates is time consuming. Time that can be more useful allocated to develop new things instead of work keeping backward compatibility.
But I may not seeing the big picture and maybe there are other task more prominent that will be better for using those collaborator time and project budget.
Not sure what will be the outcome of this proposal. But if this do not work out, I think the best thing to do is to channel this eagerness to help into a high-level impact task.
Neville FAS: yn1v
On Sat, Sep 26, 2015 at 11:21:46PM -0600, Neville A. Cross wrote:
From my point of view, Brno has most of the people (if not all) working on this porting. So, having some face to face time to engage in this initiative outside Brno will help distribute the load to other palces. This will facilitating future FADs on this topic, those can be done regionally with online support form Brno.
I know that Python 3 is important to Red Hat. (Doing the math here, Python 2.x is scheduled to be end-of-life forever in 2020. Red Hat Enterprise Linux lifetimes for the past releases go over a decade with extended support options. RHEL 7 was released just last year, and I think it's no secret to say that Red Hat is likely to release something else _before_ 2020, and releasing that with Python 3 and not Python 2 would be nice. (In fact, this was even in Denise Dumas's slides at Flock: http://www.slideshare.net/mattdm-fedora/flock-2015-what-does-red-hat-want/11)
So, if there is wide community interest in the same thing, and budget and conflicting priorities willing, I'm in support of spending Fedora community money for external-to-RH community members to collaborate on this.
The only PyCon that I have been was in 2011 and everybody was saying something along the lines of: "Python 3 is okey if they don't touch my stuff". Despite the time passed, Python 3 is not the default version. I think if advancing version number in Python is going to happen, needs some championship to make it happen (the "first" value). The number of packages having double version is increasing. The burden to maintain those duplicates is time consuming. Time that can be more useful allocated to develop new things instead of work keeping backward compatibility.
Cool, thanks for the input.
Hello.
What is the current status for proposal?
Best regards.
2015-09-28 10:16 GMT-05:00 Matthew Miller mattdm@fedoraproject.org:
On Sat, Sep 26, 2015 at 11:21:46PM -0600, Neville A. Cross wrote:
From my point of view, Brno has most of the people (if not all) working on this porting. So, having some face to face time to engage in this initiative outside Brno will help distribute the load to other palces. This will facilitating future FADs on this topic, those can be done regionally with online support form Brno.
I know that Python 3 is important to Red Hat. (Doing the math here, Python 2.x is scheduled to be end-of-life forever in 2020. Red Hat Enterprise Linux lifetimes for the past releases go over a decade with extended support options. RHEL 7 was released just last year, and I think it's no secret to say that Red Hat is likely to release something else _before_ 2020, and releasing that with Python 3 and not Python 2 would be nice. (In fact, this was even in Denise Dumas's slides at Flock: http://www.slideshare.net/mattdm-fedora/flock-2015-what-does-red-hat-want/11 )
So, if there is wide community interest in the same thing, and budget and conflicting priorities willing, I'm in support of spending Fedora community money for external-to-RH community members to collaborate on this.
The only PyCon that I have been was in 2011 and everybody was saying something along the lines of: "Python 3 is okey if they don't touch my stuff". Despite the time passed, Python 3 is not the default version. I think if advancing version number in Python is going to happen, needs some championship to make it happen (the "first" value). The number of packages having double version is increasing. The burden to maintain those duplicates is time consuming. Time that can be more useful allocated to develop new things instead of work keeping backward compatibility.
Cool, thanks for the input.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://admin.fedoraproject.org/mailman/listinfo/council-discuss
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
I'd welcome help porting s3cmd to python3. Whether that's part of a FAD or just an independent effort, I'll let the council decide. https://github.com/mdomsch/s3cmd/tree/feature/python3 has my stab at it started a couple weeks ago. Much more to go though...
Thanks, Matt
On Fri, Oct 2, 2015 at 10:49 AM, Abdel G. Martínez L. < abdel.g.martinez.l@gmail.com> wrote:
Hello.
What is the current status for proposal?
Best regards.
2015-09-28 10:16 GMT-05:00 Matthew Miller mattdm@fedoraproject.org:
On Sat, Sep 26, 2015 at 11:21:46PM -0600, Neville A. Cross wrote:
From my point of view, Brno has most of the people (if not all) working on this porting. So, having some face to face time to engage in this initiative outside Brno will help distribute the load to other palces. This will facilitating future FADs on this topic, those can be done regionally with online support form Brno.
I know that Python 3 is important to Red Hat. (Doing the math here, Python 2.x is scheduled to be end-of-life forever in 2020. Red Hat Enterprise Linux lifetimes for the past releases go over a decade with extended support options. RHEL 7 was released just last year, and I think it's no secret to say that Red Hat is likely to release something else _before_ 2020, and releasing that with Python 3 and not Python 2 would be nice. (In fact, this was even in Denise Dumas's slides at Flock: http://www.slideshare.net/mattdm-fedora/flock-2015-what-does-red-hat-want/11 )
So, if there is wide community interest in the same thing, and budget and conflicting priorities willing, I'm in support of spending Fedora community money for external-to-RH community members to collaborate on this.
The only PyCon that I have been was in 2011 and everybody was saying something along the lines of: "Python 3 is okey if they don't touch my stuff". Despite the time passed, Python 3 is not the default version. I think if advancing version number in Python is going to happen, needs some championship to make it happen (the "first" value). The number of packages having double version is increasing. The burden to maintain those duplicates is time consuming. Time that can be more useful allocated to develop new things instead of work keeping backward compatibility.
Cool, thanks for the input.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://admin.fedoraproject.org/mailman/listinfo/council-discuss
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
-- *Abdel G. Martínez L.*
council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://admin.fedoraproject.org/mailman/listinfo/council-discuss
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
On Fri, Oct 02, 2015 at 10:49:43AM -0500, Abdel G. Martínez L. wrote:
What is the current status for proposal?
We talked about it at the last council meeting -- see the log at https://meetbot.fedoraproject.org/teams/council/council.2015-09-28-17.00.log...
Primarily, we need to wait until after our upcoming budget discussion before we can commit to anything. We're also concerned about the geography.
council-discuss@lists.fedoraproject.org