Revision as of 05:00, 17 December 2014

wxPython 3

Summary

Get wxPython 3 packaged and into Fedora.

Owner

Name: Scott Talbert
Email: swt@techie.net
Release notes owner:

Current status

Targeted release: Fedora 22
Last updated: 2014-12-16
Tracker bug: <will be assigned by the Wrangler>

Detailed Description

This change proposal aims to get wxPython 3.0 (Python bindings for the wxWidgets GUI library) packaged and into Fedora. Currently Fedora has wxPython 2.8 which has not been updated since 2011. The plan is to make wxPython 3.0 co-installable with wxPython 2.8, similarly to what has been done with the wxWidgets packages (wxGTK and wxGTK3).

Benefit to Fedora

This change brings a more modern wxPython to Fedora, including support for GTK3 (currently wxPython 2.8 uses GTK2). Additionally, it moves Fedora to a supported version of wxPython.

Scope

Proposal owners:

Update existing wxPython package so that it is co-installable with wxPython 3 (currently in progress).
Get wxPython 3 through the package review process, built, and ensure it can co-exist with wxPython 2.8 package.
If all wxPython-dependent packages get moved to wxPython 3.0, consider retiring wxPython 2.8 package.

Other developers:

For maintainers of packages that depend on wxPython: switch the dependent packages to use wxPython 3.0. This can be done package-by-package as time permits. The API hasn't changed much between wxPython 2.8 and 3.0, but some changes may be required.
If a package cannot be moved to wxPython 3, after wxPython 3 is packaged, maintainers should verify that their packages continue to use wxPython 2.8 correctly when wxPython 3.0 is co-installed. A small change may be required to some packages to ensure they select wxPython 2.8 specifically.

Release engineering: None

Policies and guidelines: None

Upgrade/compatibility impact

User written wxPython applications may require a small amount of porting, but mostly wxPython 2.8 is forward compatible with wxPython 3.0.

How To Test

N/A (not a System Wide Change)

User Experience

For the most part, users will not notice any changes, other than the fact that wxPython applications will now look like GTK3 applications instead of GTK2.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

Contingency mechanism: remove wxPython 3.0 and revert any dependent packages back to wxPython 2.8
Contingency deadline: Beta Freeze
Blocks release? No
Blocks product? No

Documentation

http://wxpython.org/migrationguide.php Debian's wxPython 3.0 Migration Documentation/Tools: http://anonscm.debian.org/cgit/collab-maint/wx-migration-tools.git/tree/README

Release Notes

@@ Line 45: / Line 45: @@
 == Current status ==
 * Targeted release: [[Releases/22 | Fedora 22 ]]
-* Last updated: 2014-11-30
+* Last updated: 2014-12-16
 <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
 Bugzilla states meaning as usual:
@@ Line 69: / Line 69: @@
 # Update existing wxPython package so that it is co-installable with wxPython 3 ([https://bugzilla.redhat.com/show_bug.cgi?id=1142515 currently in progress]).
 # Get wxPython 3 through the package review process, built, and ensure it can co-exist with wxPython 2.8 package.
+# If all wxPython-dependent packages get moved to wxPython 3.0, consider retiring wxPython 2.8 package.
 * Other developers: <!-- REQUIRED FOR SYSTEM WIDE 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?-->
-# For maintainers of packages that depend on wxPython, after wxPython 3 is packaged, verify that their packages continue to use wxPython 2.8 correctly when wxPython 3.0 is co-installed.  A small change may be required to some packages to ensure they select wxPython 2.8 specifically.
+# For maintainers of packages that depend on wxPython: switch the dependent packages to use wxPython 3.0.  This can be done package-by-package as time permits.  The API hasn't changed much between wxPython 2.8 and 3.0, but some changes may be required.
-# Optional: switch dependent packages to use wxPython 3.0.  This can be done package-by-package as time permits, but may be more involved.
+# If a package cannot be moved to wxPython 3, after wxPython 3 is packaged, maintainers should verify that their packages continue to use wxPython 2.8 correctly when wxPython 3.0 is co-installed.  A small change may be required to some packages to ensure they select wxPython 2.8 specifically.
-* Release engineering: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Release engineering: None  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- 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: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Policies and guidelines: None <!-- 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. -->
@@ Line 85: / Line 86: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+User written wxPython applications may require a small amount of porting, but mostly wxPython 2.8 is forward compatible with wxPython 3.0.
 == How To Test ==
@@ Line 108: / Line 109: @@
 <!-- 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 -->
-N/A (not a System Wide Change)
+For the most part, users will not notice any changes, other than the fact that wxPython applications will now look like GTK3 applications instead of GTK2.
 == Dependencies ==
@@ Line 118: / Line 119: @@
 == 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.  -->
-* Contingency mechanism: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency mechanism: remove wxPython 3.0 and revert any dependent packages back to wxPython 2.8 <!-- 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. -->
-* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Contingency deadline: Beta Freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- 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) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-* Blocks product? N/A (not a System Wide Change) <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
+* Blocks product? No <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
 == Documentation ==
@@ Line 129: / Line 130: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+http://wxpython.org/migrationguide.php
+Debian's wxPython 3.0 Migration Documentation/Tools: http://anonscm.debian.org/cgit/collab-maint/wx-migration-tools.git/tree/README
 == Release Notes ==
@@ Line 145: / Line 147: @@
 <!-- Select proper category, default is Self Contained Change -->
-[[Category:SelfContainedChange]]
+<!-- [[Category:SelfContainedChange]] -->
-<!-- [[Category:SystemWideChange]] -->
+[[Category:SystemWideChange]]

Search

Changes/wxPython3: Difference between revisions