EPEL Python 3 for 7?

[Stephen Gallagher]

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

On 01/15/2014 02:16 AM, Bohuslav Kabrda wrote:
> ------------------------------------------------------------------------
>
> 
> 
> 
> 
> On 14 January 2014 09:57, Orion Poplawski <orion at cora.nwra.com 
> <mailto:orion at cora.nwra.com>> wrote:
> 
> It seems like it would be nice to have python 3 in EPEL 7. Anyone
> willing to maintain it there?
> 
> It seems to build fine: 
> http://copr-fe.cloud.fedoraproject.org/coprs/orion/Python3_EPEL7/builds/
>
> 
> 
> Well  a couple of other things would be needed beyond just
> maintenance:
> 
> 1) Does providing python-3.4 mean that 3.4 will be the only python 
> every provided by EPEL? 2) If it doesn't then how are upgrades from
> 3.4 to 3.5 to 3.6 going to be handled?
> 
> -- Stephen J Smoogen.
> 
> 
> Well the problem is that once you provide a build for EPEL, you 
> shouldn't really do major updates [1], so it seems we would be
> stuck with whatever we build for 10+ years. I don't like that very
> much. We could probably do python3.4, python3.5 etc, but that'd
> probably require some modifications to dependency generators,
> etc... I'm not going to stay in anyones way to do this, but I won't
> do it myself.
> 

Perhaps this would be a good time to reopen the conversation of
minor-release policy changes?

RHEL releases approximately every six months with a minor release. It
seems fair to allow major EPEL upgrades to occur in sync with those
releases as well.

So my suggestion would be that EPEL should have two branches for EPEL
7: the epel7 branch and the epel7-pending branch. The idea of this
second branch would be sort of an EPEL Rawhide, where major upgrades
can be staged. Then, when RHEL releases a minor update (such as RHEL
7.1), we have a (one-month?) integration period where we ensure that
packages in epel7-pending work on the newest minor release and then
they are merged back to epel7. If they miss this merge window, they
have to wait until the next minor release.

This allows us a regular, planned ability to move to newer EPEL
packages, without destabilizing EPEL in general.

In order to not make this a willy-nilly breakage every six months, we
might want to set some limits (or at least guidelines) on what is or
is not allowed to upgrade at the minor release. But I'd be fine with
deferring making such decisions until we have a demonstrated need
(i.e. fix it only if packages/EPEL is actually breaking).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLWqgIACgkQeiVVYja6o6O2swCgrcc3APBS1pyNFQFKAGP7gyJy
Xe0AniOEU8xDZIkRWMemm569Rq0uvgyU
=ItqY
-----END PGP SIGNATURE-----