-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josh Boyer wrote: > On Sat, 1 Sep 2007 10:38:07 +0200 > Patrice Dumas <pertusus@xxxxxxx> wrote: > >> On Fri, Aug 31, 2007 at 02:35:11PM -0500, Josh Boyer wrote: >>> On Fri, 31 Aug 2007 15:02:37 -0400 >>> Ignacio Vazquez-Abrams <ivazqueznet@xxxxxxxxx> wrote: >>> >>>> Anyone working on a package for this yet? >>>> >>>> http://www.python.org/download/releases/3.0/ >>> You really want to have a parallel installable alpha package of >>> python? I think that would be a no-no. If we allowed that, the we >>> should allow a parallel installable compat-python package. >> Do we disallow that? In my opinion there shouldn't be a possibility for >> anybody to disallow a free software package to enter devel. And a >> package of enough quality to enter stable releases. > > We do. FESCo has gone over this at least twice. No parallel > installable python packages have been allowed. For a very long and > agonizing read, see the zope/plone thread from a year or so ago. > We don't disallow it. (current, ongoing, made into policy) We have (almost) disallowed it. (One time decision, made in the past, specific circumstances) I make this distinction because it's a definite case-by-case basis. Jeremy as the python maintainer wanted to outright ban compat-python. The zope/plone maintainer wanted to have a compat-python so that zope/plone could run. FESCo disagreed as to whether we should ban or not. We could all agree that the compat-python maintainer would have to show that they had both the time and the ability to maintain such a package for it to be allowed in. This is for several reasons: 1) python is a "framework": other modules extend its functionality using the API it provides and would need separate packaging for the compat-python package. It you wanted docutils for both the mainline and compat python, you would need to have two binary packages, one for each version. 2) python is central to our distro. If parallel installing was not done correctly, it could cause breakage for a lot of thing. FESCo decided that we needed to ask the zope plone maintainer to make an honest decision of whether he had the time to devote to maintaining the compat-python package for the life of the distro releases he wanted to support. He had, meanwhile, decided that he wanted to take one of the other options: maintain python2.4 and zope/plone in a 3rd party repo until zope/plone could run on Fedora. So in the end, we actually did not have to make a decision. </history> After some thinking on this, I think we should be whole heartedly for a parallel installable python3.0 *on rawhide*. Why? 1)python3.0 is a major break from python2.x. It's almost guaranteed that every python package we have is going to break. 2) Python upstream is planning to release 2.6.x and 3.x packages in parallel for a reasonably long time. We need to gain experience with python3.x so we know whether we want to jump to 3.x when it comes out, parallel install python-2.6 and python-3.x, or stick with python-2.6 until the distro as a whole has a chance to migrate to 3.x. Having a parallel installable package on rawhide allows us to make a better decision when we need to decide how we're going to move to python-3.x for the rest of the distribution. One of the arguments against compat-python packages were that they contradicted our nature as a "bleeding edge distro" where we should be working to port code forward from python2.4 to python2.5 instead of creating python2.4 packages as a crutch for software to rely upon. That argument does not apply to python3.0 packages. As for letting python3 into a release, I think that depends on some of the same factors as the compat- package. Who wants to maintain it? Does that person (or team of people) have the time to deal with issues? One thing about python3 being a preview instead of a compat package is that the job of a compat package is to make things run. If it breaks, it's a direct contradiction of its reason for existing. A preview package is to show people what the future is going to look like. If it breaks, it hurts one of its purposes (allowing people to make their code run on the new version) but doesn't compromise all of its value in the same way as a compat package. - -Toshio - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG2YWqX6yAic2E7kgRApj3AJ9/fhiycIa9uRl7XQpaJvGsl4o3wgCeMhzE sOZ2J4wVb62DiPCjKz7+91Q= =vHh7 -----END PGP SIGNATURE----- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
