< Changes
(Start change page with some general info) |
(Finish the rough proposal, to be reviewed before submitting) |
||
| Line 62: | Line 62: | ||
== Scope == | == Scope == | ||
<!-- What work do the developers have to accomplish to complete the change 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 developers have to accomplish to complete the change 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?--> | ||
Compare with the [[Features/Python_3.3| Python 3.3 feature page]]. | |||
We need to wait for Python 3.4 to reach feature freeze, so that the bytecode format for .pyc files is frozen, together with the ABI for extension modules. | |||
At that point we can rebase python3 to the latest release candidate of that code. We would then need to rebuild all python 3 packages. See https://fedoraproject.org/wiki/Python3#Python_3_already_in_Fedora | |||
For bonus points, we ought to tell "file" and "rpmlint" about the new bytecode format for .pyc files. | |||
Note that the suffix of some files should change, and this may require slight packaging tweaks in the various packages that ship Python 3 code: | |||
* bytecode files changing from '''.cpython-33.pyc''' (and .cpython-33.pyo) to '''.cpython-34.pyc''' (and .cpython-34.pyo) | |||
* extension modules changing from '''.cpython-33m.so''' to '''.cpython-34m.so''' and '''.cpython-33dm.so''' to '''.cpython-34dm.so''' | |||
Notes about porting from Python 3.3 can be found at http://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4. | |||
* Proposal owners: | * Proposal owners: | ||
This change is isolated to Python 3 stack, which is not yet crucial for Fedora. Still, as the time of moving Fedora to Python 3 is hopefully approaching, we need to do this very cautiously. I will prepare Python 3.4 prerelease RPMs in a private repo and will do a test rebuild of all Python 3 dependent packages, filing bugs/sending patches to upstreams. This will give us a good notion of how drastic this change will be and whether or not we really want to undergo it. Overall, the change will consist of these steps: | |||
** Build Python 3.4 prerelease in a private repo, continuously upgrading with latest upstream prerelease versions. | |||
** Build Python 3 dependent packages in the repo continuously. | |||
** Some time before final release (e.g. around 3.4.0 candidate 1: January 19, 2014) request a side tag in Koji and start rebuilding there. | |||
** If everything goes well, merge into F21. | |||
<!-- 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?--> | ||
* Other developers: | * Other developers: | ||
I'll gladly accept any help with rebuilding/porting/patching/bug reporting of dependent packages as well as suggestions for Python 3.4 packaging itself. When we're sure that we really want to do the transition, it'd be great if package owners rebuild their packages themselves. | |||
<!-- 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?--> | <!-- 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: | * Release engineering: | ||
We will most likely require a side tag in Koji for this. | |||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | ||
* Policies and guidelines: | * Policies and guidelines: | ||
Probably none. | |||
<!-- 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. --> | ||
| Line 79: | Line 101: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.3 is forward compatible with Python 3.4. | |||
== How To Test == | == How To Test == | ||
| Line 97: | Line 119: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Interested testers do not need special hardware. If you have a favorite Python 3 script, module, or application, please test it with Python 3.4 and verify that it still works as you expect. | |||
My own test plan: | |||
* Smoketest of the interpreter | |||
* Run the upstream regression test suite (this is done during %check) | |||
== 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 --> | ||
Users should not notice any difference, other than the availability of the 3.4 interpreter | |||
== Dependencies == | == Dependencies == | ||
| Line 108: | Line 134: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
See notes in "Scope" above. | |||
== Contingency Plan == | == Contingency Plan == | ||
| Line 122: | Line 148: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
As mentioned in "Scope" above, we will be building everything in Koji sidetag, so we may decide not to merge it in F21, if anything seems to be wrong. | |||
== Release Notes == | == Release Notes == | ||
| Line 130: | Line 156: | ||
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. | Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. | ||
--> | --> | ||
http://docs.python.org/dev/whatsnew/3.4.html | |||
[[Category:ChangePageIncomplete]] | [[Category:ChangePageIncomplete]] | ||
| Line 138: | Line 166: | ||
<!-- Select proper category, default is Self Contained Change --> | <!-- Select proper category, default is Self Contained Change --> | ||
[[Category:SelfContainedChange]] | <!-- [[Category:SelfContainedChange]] --> | ||
[[Category:SystemWideChange]] | |||
Revision as of 07:52, 26 August 2013
Python 3.4
Summary
Update the Python 3 stack in Fedora from Python 3.3 to Python 3.4.
Owner
- Name: Slavek Kabrda
- Email: <bkabrda@redhat.com>
- Release notes owner:
Current status
- Targeted release: Fedora 21
- Last updated: August 26
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
Python 3.4 adds numerous features and optimizations. See the upstream notes at http://www.python.org/dev/peps/pep-0429/#features-for-3-4 and http://docs.python.org/dev/whatsnew/3.4.html.
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.
Scope
Compare with the Python 3.3 feature page.
We need to wait for Python 3.4 to reach feature freeze, so that the bytecode format for .pyc files is frozen, together with the ABI for extension modules.
At that point we can rebase python3 to the latest release candidate of that code. We would then need to rebuild all python 3 packages. See https://fedoraproject.org/wiki/Python3#Python_3_already_in_Fedora
For bonus points, we ought to tell "file" and "rpmlint" about the new bytecode format for .pyc files.
Note that the suffix of some files should change, and this may require slight packaging tweaks in the various packages that ship Python 3 code:
- bytecode files changing from .cpython-33.pyc (and .cpython-33.pyo) to .cpython-34.pyc (and .cpython-34.pyo)
- extension modules changing from .cpython-33m.so to .cpython-34m.so and .cpython-33dm.so to .cpython-34dm.so
Notes about porting from Python 3.3 can be found at http://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4.
- Proposal owners:
This change is isolated to Python 3 stack, which is not yet crucial for Fedora. Still, as the time of moving Fedora to Python 3 is hopefully approaching, we need to do this very cautiously. I will prepare Python 3.4 prerelease RPMs in a private repo and will do a test rebuild of all Python 3 dependent packages, filing bugs/sending patches to upstreams. This will give us a good notion of how drastic this change will be and whether or not we really want to undergo it. Overall, the change will consist of these steps:
- Build Python 3.4 prerelease in a private repo, continuously upgrading with latest upstream prerelease versions.
- Build Python 3 dependent packages in the repo continuously.
- Some time before final release (e.g. around 3.4.0 candidate 1: January 19, 2014) request a side tag in Koji and start rebuilding there.
- If everything goes well, merge into F21.
- Other developers:
I'll gladly accept any help with rebuilding/porting/patching/bug reporting of dependent packages as well as suggestions for Python 3.4 packaging itself. When we're sure that we really want to do the transition, it'd be great if package owners rebuild their packages themselves.
- Release engineering:
We will most likely require a side tag in Koji for this.
- Policies and guidelines:
Probably none.
Upgrade/compatibility impact
User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.3 is forward compatible with Python 3.4.
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.4 and verify that it still works as you expect.
My own test plan:
- Smoketest of the interpreter
- Run the upstream regression test suite (this is done during %check)
User Experience
Users should not notice any difference, other than the availability of the 3.4 interpreter
Dependencies
See notes in "Scope" above.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
Documentation
As mentioned in "Scope" above, we will be building everything in Koji sidetag, so we may decide not to merge it in F21, if anything seems to be wrong.