-Dave
On Thu, Jan 16, 2014 at 7:32 AM, Dave Johansen <davejohansen(a)gmail.com>wrote:
On Thu, Jan 16, 2014 at 8:03 AM, Toshio Kuratomi
<a.badger(a)gmail.com>wrote:
> On Jan 16, 2014 1:08 AM, "Matthias Runge" <mrunge(a)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.
>
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
epel-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel