On Jan 16, 2014 1:08 AM, "Matthias Runge" <mrunge@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