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. In general: when allowing package upgrades, there might be manual steps required after package upgrade, like starting database migrations, tweaking config files to adjust to new syntax, etc. I'm not sure, if that is really acceptable. Thoughts? Matthias _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
