From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
m (Notes from the upgrade link)
 
(24 intermediate revisions by 3 users not shown)
Line 58: Line 58:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1565020 #1565020]
* Release Notes tracking: [https://pagure.io/fedora-docs/release-notes/issue/133 #133]


== Detailed Description ==
== Detailed Description ==


Python 3.7 adds numerous features and optimizations. See the upstream notes at [https://www.python.org/dev/peps/pep-0537/#features-for-3-7 Features for 3.7] and [https://docs.python.org/3.7/whatsnew/3.7.html What's new in 3.7].  
Python 3.7 adds numerous features and optimizations. See the upstream notes at [https://www.python.org/dev/peps/pep-0537/#features-for-3-7 Features for 3.7] and [https://docs.python.org/3.7/whatsnew/3.7.html What's new in 3.7].
 
=== Important dates ===
 
* 2018-06-11 Python 3.7.0 candidate 1
* 2018-06-27 Python 3.7.0 final
* 2018-07-11 Fedora 29 Mass Rebuild
* 2018-08-14 Fedora 29 Change Checkpoint: Completion deadline (testable)
 
(From [https://www.python.org/dev/peps/pep-0537/#schedule Python 3.7 Release Schedule] and [[Releases/29/Schedule|Fedora 29 Release Schedule]].)
 
=== PEP 552 – Deterministic pycs ===
 
One change is notable from the packaging viewpoint: [https://www.python.org/dev/peps/pep-0552/ PEP 552] – “Deterministic pycs”. We may decide to use the new <code>UNCHECKED_HASH</code> mode, which would mean that bytecode cache is not validated on import, i.e. changing a RPM-installed <code>*.py</code> file manually will have no effect (unless the corresponding <code>__pycache__/*.pyc</code> is updated or removed). '''We haven't decided for this.'''
 
=== Notes from the upgrade ===
 
There are notes from this upgrade available, so future upgrades may go smoother: [[SIGs/Python/UpgradingPython]]


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 71: Line 89:


== Scope ==
== Scope ==
We will coordinate the work in a side tag and merge when ready.
* Proposal owners:
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
*# Retire {{package|python37}} from F29+
*# Retire {{package|python37}} from F29+ (done)
*# Update  {{package|python3}} to what was in {{package|python37}}  
*# Update  {{package|python3}} to what was in {{package|python37}} (done)
*#* Mass rebuild all the packages that BR {{package|python3}}/{{package|python3-devel}}/... (~2300 listed in [http://fedora.portingdb.xyz/ Python 3 Porting Database for Fedora])  
*#* Mass rebuild all the packages that BR {{package|python3}}/{{package|python3-devel}}/... (~2300 listed in [http://fedora.portingdb.xyz/ Python 3 Porting Database for Fedora]) (built everything that was buildable)
*# Reintroduce {{package|python36}} from Fedora 25. Update it to have all fixes and enhancements from {{package|python3}} in Fedora 28 (or 29 before this change)
*# Reintroduce {{package|python36}} from Fedora 25. Update it to have all fixes and enhancements from {{package|python3}} in Fedora 28 (or 29 before this change) (package ready in git, will arrive on mass rebuild)


* Other developers: Maintainers of packages that fail to rebuild during the mass rebuild will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with upstreams first and/or applying downstream patches. Also the package maintainers should have a look at: [https://docs.python.org/3.7/whatsnew/3.7.html#porting-to-python-3-7 Porting to Python 3.7]. And python-maint team will be available to help with fixing issues.
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Fedora QA: Based on some troubles with the [[Changes/Python3.6|change to 3.6]], we'd like to have an ack from QA before we merge the side tag.
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/7390 #7390] <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> A targeted rebuild for all python packages will be required, before the mass rebuild.
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: nope <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: nope <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->


* Trademark approval: N/A (not needed for this Change)
* Trademark approval: nope
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


Line 98: Line 120:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.6 is forward compatible with Python 3.7.


== How To Test ==
== How To Test ==
Line 116: Line 138:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
 
Interested testers do not need special hardware. If you have a favorite Python 3 script, module, or application, please test it with Python 3.7 and verify that it still works as you expect. You can test it using {{package|python37}} even before this change is implemented, in Fedora 27 or 28.
 
Once the change is in place, test if you favorite Python apps are working as they were before. File bugzillas if they don't.


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
Regular distro users shouldn't notice any change in system behavior other than the Python 3 interpreter will be in version 3.7.


== Dependencies ==
== Dependencies ==
Line 127: Line 152:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
~2300 packages depends on {{package|python3}}. See scope section.


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.6 version (never needed before) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: TBD <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? No <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
Line 143: Line 168:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
[https://www.python.org/dev/peps/pep-0537/ Python 3.7 Release Schedule]
 
[https://www.python.org/dev/peps/pep-0537/#features-for-3-7 Features for 3.7]
 
[https://docs.python.org/3.7/whatsnew/3.7.html What's new in 3.7]
 
[https://docs.python.org/3.7/whatsnew/3.7.html#porting-to-python-3-7 Porting to Python 3.7]


== Release Notes ==
== Release Notes ==
Line 152: Line 183:
-->
-->


[[Category:ChangePageIncomplete]]
* Release Notes tracking: [https://pagure.io/fedora-docs/release-notes/issue/133 #133]
 
[[Category:ChangeAcceptedF29]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 15:46, 9 July 2018


Python 3.7

Summary

Update the Python 3 stack in Fedora from Python 3.6 to Python 3.7.

Owner

  • Email: python-maint@redhat.com
  • Release notes owner:

Current status

Detailed Description

Python 3.7 adds numerous features and optimizations. See the upstream notes at Features for 3.7 and What's new in 3.7.

Important dates

  • 2018-06-11 Python 3.7.0 candidate 1
  • 2018-06-27 Python 3.7.0 final
  • 2018-07-11 Fedora 29 Mass Rebuild
  • 2018-08-14 Fedora 29 Change Checkpoint: Completion deadline (testable)

(From Python 3.7 Release Schedule and Fedora 29 Release Schedule.)

PEP 552 – Deterministic pycs

One change is notable from the packaging viewpoint: PEP 552 – “Deterministic pycs”. We may decide to use the new UNCHECKED_HASH mode, which would mean that bytecode cache is not validated on import, i.e. changing a RPM-installed *.py file manually will have no effect (unless the corresponding __pycache__/*.pyc is updated or removed). We haven't decided for this.

Notes from the upgrade

There are notes from this upgrade available, so future upgrades may go smoother: SIGs/Python/UpgradingPython

Benefit to Fedora

Fedora aims to showcase the latest in free and open source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3.7.

Scope

We will coordinate the work in a side tag and merge when ready.

  • Other developers: Maintainers of packages that fail to rebuild during the mass rebuild will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with upstreams first and/or applying downstream patches. Also the package maintainers should have a look at: Porting to Python 3.7. And python-maint team will be available to help with fixing issues.
  • Fedora QA: Based on some troubles with the change to 3.6, we'd like to have an ack from QA before we merge the side tag.
  • Release engineering: #7390 A targeted rebuild for all python packages will be required, before the mass rebuild.
  • Policies and guidelines: nope
  • Trademark approval: nope

Upgrade/compatibility impact

All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.6 is forward compatible with Python 3.7.

How To Test

Interested testers do not need special hardware. If you have a favorite Python 3 script, module, or application, please test it with Python 3.7 and verify that it still works as you expect. You can test it using Package-x-generic-16.pngpython37 even before this change is implemented, in Fedora 27 or 28.

Once the change is in place, test if you favorite Python apps are working as they were before. File bugzillas if they don't.

User Experience

Regular distro users shouldn't notice any change in system behavior other than the Python 3 interpreter will be in version 3.7.

Dependencies

~2300 packages depends on Package-x-generic-16.pngpython3. See scope section.

Contingency Plan

  • Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.6 version (never needed before)
  • Contingency deadline: TBD
  • Blocks release? No
  • Blocks product? No

Documentation

Python 3.7 Release Schedule

Features for 3.7

What's new in 3.7

Porting to Python 3.7

Release Notes

  • Release Notes tracking: #133