On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi <[email protected]> wrote:
> On Jan 16, 2014 1:08 AM, "Matthias Runge" <[email protected]> > 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. > My personal vote would be for either the parallel versions of #1 so people aren't forced to upgrade or #2 with maintaining the priority for existing deployments. EL provides a known/stable base and I think that EPEL should maintain that same philosophy for at least the frameworks and language stacks.
_______________________________________________ epel-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/epel-devel
