Python 3.0

[Toshio Kuratomi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Josh Boyer wrote:
> On Sat, 1 Sep 2007 10:38:07 +0200
> Patrice Dumas <pertusus at free.fr> 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 at gmail.com> 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-----