EPEL RFC: Strategy for python3 versions

Wed Apr 30 13:51:01 UTC 2014

I wonder if the softwarecollections.org repos might be a better choice 
for this.  All the userspace tools already exist in 5, 6 and 7.

Pat

On 04/29/2014 08:22 PM, Orion Poplawski wrote:
> -----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-----
> _______________________________________________
> epel-devel mailing list
> epel-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel

-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/