EPEL6 When to go out of Beta?

Kevin Fenzi kevin at scrye.com
Tue Nov 16 05:31:38 UTC 2010


On Mon, 15 Nov 2010 17:03:49 -0500
Stephen Gallagher <sgallagh at redhat.com> 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?

This would be a lot more infrastructure work I fear... 

> 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.

So how would that work for the git/repo/build side? 
each package would have a EL-5.1/EL-5.2/EL-5.3/EL-5.4/EL-5.5/etc
branch? If you wanted to update them all thats 6-9 builds? 

> 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.

So, a new minor rev would allow any new feature, but you would have to
keep the old rev on the old version? Couldn't that get confusing? 
Would we need bug components then for each of the streams then I guess?

I think it could be ok, but not sure we have the infrastructure
manpower for it. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20101115/7fb1646b/attachment.sig>


More information about the epel-devel-list mailing list