-----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 or...@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel