105
edits
Changes
Jump to navigation
Jump to search
Line 85:
Line 85: + + Line 132:
Line 134: + + + + + + + + + +
no edit summary
* The result is that all unported/unmodified activities (without the GTK3_PORTED file) would <tt>import sugar.foo</tt> as before, but the above trick that modifies Python's module table would result in them (transparently, magically, automatically) being redirected to sugar_gtk2.foo.
* The result is that all unported/unmodified activities (without the GTK3_PORTED file) would <tt>import sugar.foo</tt> as before, but the above trick that modifies Python's module table would result in them (transparently, magically, automatically) being redirected to sugar_gtk2.foo.
* At the end of the transition period, sugar_gtk2 would be deleted in entirity, the above addition to sugar-activity would be dropped, and activities could drop the GTK3_PORTED files at their leisure.
* At the end of the transition period, sugar_gtk2 would be deleted in entirity, the above addition to sugar-activity would be dropped, and activities could drop the GTK3_PORTED files at their leisure.
Further consideration must be given to sugar-base. This package installs some classes which are then used by sugar-toolkit, so they would need to be duplicated into sugar_gtk2. This may be a good opportunity to consider merging sugar-base with sugar-toolkit.
=== Proposed plan of action ===
=== Proposed plan of action ===
Sugar would start depending on PyGObject built with gobject introspection support, GTK3, and (at the end of the transition period) would drop its dependencies on GTK2 and PyGTK.
Sugar would start depending on PyGObject built with gobject introspection support, GTK3, and (at the end of the transition period) would drop its dependencies on GTK2 and PyGTK.
== Contingency plan ==
Hopefully, this page has been convincing in that this change is of necessity. Either way, we should consider our options for the case where this migration is found to be more difficult than predicted.
As this migration would take over the course of a major release (or perhaps 2-3 of them, as components are ported individually), our users have the option to remain on older releases in the face of stability issues, and as developers we have the option of delaying major releases until things are ready.
If new PyGI/GTK3-based major releases are found to be unstable, we also have the option of allowing interested community members to pick up maintenance of older GTK2-based release branches (e.g. 0.94) with a "master first" commit policy. Personally, I would suggest that it would be a better use of resources to have those people help fix any problems with the GTK3 version, but as an open source community this is something we must be open to.
In the event of problems in the GTK3 version of sugar-toolkit, activity authors have the (default) choice of staying with GTK2. The transition period before the GTK2 version is removed would obviously be extended in the face of significant problems with GTK3 version.
== Release Notes ==
== Release Notes ==