On Wed, Jan 15, 2014 at 8:32 AM, Stephen Gallagher <sgall...@redhat.com>wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/15/2014 02:16 AM, Bohuslav Kabrda wrote: > > ------------------------------------------------------------------------ > > > > > > > > > > > > On 14 January 2014 09:57, Orion Poplawski <or...@cora.nwra.com > > <mailto:or...@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). > My understanding is that RHEL minor release can include "major upgrades" to non-core parts (LibreOffice, Firefox, etc) but that core parts (the kernel, compiler, python version, etc) don't see "major upgrades". I personally like that model and think that it provides the stability needed for an enterprise class system, so I think that those same general guidelines should be upheld by the EPEL. If you really want/need the latest and greatest of everything all the time, then I believe that Fedora is probably a better fit than RHEL.
_______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
