TL;DR
- stability is nice
- longer RHEL lifecycle = less useful EPEL if there are no updates
- shouldn't be expected to solve local admin software management issues
-
So...
I agree with a lot of the overall concerns about stability, however
realistic expectations should be set on volunteers. I also think we'd
want to avoid deviating to far from RHEL's update cycle beyond is
absolutely necessary (i'm referring to the concept of dot release
repositories).
As an administrator I know it has annoyed me for
years that I can't specifically get many apps from EPEL just because of
the major version update rule. In my experience I've ended up
repackaging the Fedora RPM because EPEL was just too far behind.
So, first, be patient with me as I look at RHEL for a second.
* Red Hat's release cycle for RHEL is ~8m per dot release (roughly averaged)
* RHEL is now on a 13 year support cycle (
https://access.redhat.com/support/policy/updates/errata/)
*
Updated always go into the same repository (Unless you subscribe to
Extended Update Support (EUS), but I believe that is a separate
repository anyway)
Based on the above, most people have come up with a way to handle deployment of updates in their environment:
1: paying extra to red hat for EUS
2: running a local repository that they manage the releases through (satellite or manual)
3: auto or manually updating the boxes on a schedule
4: updating haphazardly
5: other?
So, unless someone wants to turn EPEL into a paid service, #1 is out (hey... thats an interesting concept...)
To me (and most people I know) running your own local repository as a 'stability' control
is way more efficient for the administrator.
If you are doing 3
and 4 then I don't know that requesting the EPEL volunteers to
provide that level of stability is very reasonable.
I can however appreciate that there are two primary sets of users from what I've read on these conversations:
1: Those that don't want updates that change api compatibility
2: Those who need the newer version for X reason
I'm personally inclined to lean toward the concept I was pushing in the thread discussing multiple versions [1]. I'd imagine that a 'api stable' repo and a 'rolling' repo would be less support effort than attempting to manage >8 repositories per major release and the security updates that need to be applied on older version.
That being said I could about see doing a point in time 'snapshot' using hardlinks of the single repository whenever a dot release comes out. But then what about security updates?
I realize that whichever route we go, work is required, but I also assume that as a given at this point of the conversation.
-greg