EPEL6 When to go out of Beta?

BJ Dierkes wdierkes at 5dollarwhitebox.org
Mon Nov 15 22:44:36 UTC 2010

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.


More information about the epel-devel-list mailing list