EPEL RFC: Strategy for python3 versions

Wed Apr 30 01:22:40 UTC 2014

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

On 04/29/2014 05:54 PM, Toshio Kuratomi wrote:
> Hi guys,
> 
> Orion has submitted a python34 package for EPEL and I'm going to
> review them soon if no one beats me to it.  In parallel with
> getting that approved I'd like to ask about the general strategy
> we'd like to take with maintaining python3 in EPEL.
> 
> Python3 is an evolving language.  New 3.N releases bring new
> features, bugfixes, and both backwards compatibility breaking and
> backwards compatibility enhancing changes (For instance, 3.3
> brought the ability to mark regular text strings with the "u"
> prefix to match with python2.x.  3.5 will bring back formatting
> methods for byte strings.)

...

> I'd like to propose that we attempt to maintain 2 python3 releases
> at any one time.  We'll create python3.4 now.  When python3.5 comes
> out in 18 months (less since python3.4 has been out for several
> months), we'll package that in addition.  When python3.6 comes out
> (3 years), we'll package that and retire python3.4.
> 
> Pluses: * This gives users some time to verify that their homegrown
> applications continue to work with the newer python3 package that
> we produce before the old one goes EOL. * This means that we're
> only working on 3 versions of python3 at a time (the two we expect
> users to use and the next version that we're tracking as upstream
> works on finishing it). * This gives us a chance to update
> frameworks, libraries, and other stacks of software built on top of
> python3 at the same time as we create the new interpreter package.
> So you could get python3.4 with Django-1.6.x  and you could get
> python3.5 with Django-1.8.x
> 
> Negatives: * Users will have to reverify and port apps written
> against python3 to the new interpreter version sometime in the 3
> year lifespan of the python3 package they originally wrote it
> against. * Package maintainers who are creating packages that run
> on python3 will need to submit new packages for python3.4,
> python3.5, etc. * Users may have to port to both new versions of
> python3 and to new versions of some libraries they depend on
> (because we took the opportunity to update those libraries for the
> new python3 interpreter stack).

So, I want to be explicit as to how we handle python3 modules in EPEL.
 Originally I was hoping we could simply have python3.4 provide
python3 and maintainers could branch their current Fedora python
modules for epel7 and build as is resulting in python3-module packages
as in Fedora.

However, I don't see how we transition easily to the next python3
release.  I suppose we could do a side tag and rebuild everything then
have a flag day release.  Does this seem workable (I don't think so)?

If we're going to require having python34-module packages are we going
to require new reviews, or can we simply have people name them with
%package -n python34-module in the epel7 branch?  Would we have people
maintain multiple versions at a time in a package?  This seems like
the workable version.  I'm afraid that requiring new review all the
time will be a serious impediment.

We'll have %{__python34} etc macros then too.

> Alternatives: * Never retire the python3 packages.  This leaves us
> trying to support the release once upstream stops support.  Since
> new python3 releases are in demand, we'd probably end up trying to
> maintain all of the python3 releases that came out between when
> RHEL-N was released and when RHEL-N+1 releases (because maintainer
> focus usually shifts to building packages for RHEL-N+1 then). *
> Retire the python3 packages when upstream stops support.  This
> defers the pain for users (They can use a python3.N version for
> about 5 years instead of about 3 years).  However, it means that
> we're maintaining 4-5 versions of python3 at a time instead of 2-3
> 
> 
> What do people think?  Is this something we can do within the
> policies of EPEL?  Does it make sense to go forward with this?  Is
> it better to go with one of the alternatives?

I like the plan of supporting 2 versions at a time.  I'm willing to
defer deciding on what the next version should be till later.  Perhaps
3.5 won't be all that compelling and we'll want to wait for 3.6.

Finally:
   python34-3.4
or python3.4-3.4
or python-3.4-3.4
or python3-3.4-3.4?

Keep provides python(abi) = 3.4?

- -- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion at cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNgUFwACgkQORnzrtFC2/ujzQCguem5bziFQQZzn1WfLPZaPbuy
adMAoMOmF2Al81HWqxCFGYJgBr5UZcjZ
=OMyV
-----END PGP SIGNATURE-----