EPEL Python 3 for 7?

[Toshio Kuratomi]

On Jan 16, 2014 1:08 AM, "Matthias Runge" <mrunge at matthias-runge.de> wrote:
>
> On 01/15/2014 04:32 PM, Stephen Gallagher wrote:
>
> >
> > 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).
> Interesting idea, I like that.
>
> This would be a place to put e.g django-1.6.
>
Although I would favor being able to deprecate one version of a package and
introduce a newer incompatible version in some manner I have to point out
here that if we "set some limits" to avoid breaking things then those
limits would almost certainly cover frameworks and language stacks like
python and django.

This is the basic problem that we inevitably face - people who have
deployed software that relies on the old version inevitably do not want a
new, incompatible version to appear in the reps that causes them to have to
do extra porting work.  People who have not yet deployed (or written) their
software want the latest and greatest version of the software so they can
build it using features provided by the latest version.

I think there's two classes of upgrade policy that we might implement to
address this.

1) we think we have enough manpower in epel to support more packages.  If
this is the case then we should be looking at ways to support more than one
version of packages on the repository.  Ideas here include:

+ parallel versions (what we do today.  Parallel installable Python3.3 and
python3.4 packages are in this vein).

+ multiple versions that have explicit conflicts between them.  Conflicts
aren't allowed in fedora packages but this could be an epel difference.

2) we don't feel we have the manpower to support multiple versions.  In
this case we have to decide whether we are more strongly in favor of
supporting existing deployments or supporting new deployments.  Existing
deployments is our default now.  Our story for new deployments is that we
must have parallel installable versions to make that use case work.
Sgallagh's proposal turns that around so that we favour new deployments'
needs more than existing ones.  There are ways to improve it for existing
deployments - for instance we could create a new repository for each of
these point releases. Those repositories could be open or closed for new
packages/updates depending on how much manpower we think we have to throw
at the problem.

-Toshio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140116/79358732/attachment.html>