On Nov 15, 2010, at 4:03 PM, Stephen Gallagher wrote:
I vote for b) with the below as rationale:
As a related question: for EPEL 6 can we discuss the possibility of
having EPEL6.1, EPEL6.2 releases where we consider the possibility of
releasing minor and (possibly) major package updates?
RHEL itself will sometimes rev minor and major versions of packages
during Y-stream releases (6.1, 6.2, etc.) I personally think that we
should consider doing something similar in EPEL. One month after each
RHEL Y-stream release, we should allow similar updates to happen in EPEL.
Logistically, I'd be suggesting that we should maintain a primary EPEL6
branch and an ongoing EPEL6-beta branch. Individual packages could then
be merged into the EPEL6 primary branch one month or so after a RHEL
Y-stream release.
It would make maintaining packages for EPEL a lot more approachable if
there was a plan for when it would be okay to have new functionality
updates. It would also be predictable from a consumer's perspective.
On the subject of point releases... but not exactly the same reasoning... I've brought
up the idea of supporting EUS (z-stream) in the past which was more or less shot down.
Being that we are still in EPEL 6 beta times... I figure its worth asking again, is there
any thoughts of supporting EUS? Currently, if any RHEL users out there are using EPEL
base on an older EUS point release (like 5.4z) ... some things have the potential to break
(memcached due to libevent, etc).
The reason I ask is... if we build out the capability to build against up coming point
releases separately, how much more work would it be to keep older point releases around...
allowing EUS users to access EPEL 6.x for packages that are built against their EUS point
release.
Just thought I'd throw that into the mix.
---
derks